Developer forum

Hi Nicolai,

This is perfect and clear for me, thanks.

Best Regards,

Nuno Aguiar

Hi Nicolai,

Any way we can exceed the 100 limit?

I just though about it 3 times like you suggested, but on a project we have, we need to show "Models" (custom fields) based on "Makes" (similar to show "Regions" depending on the "Country" selected), but this is for bearings, so I get a huge list of Makes and Models.

Here's what we need to replicate.

• User selected a Make
• We refresh the page and show him a huge list of Models (based on the make)
  We group it by letter, so in the template the user can click on "J" and goes there
• Once the user selects the model, he gets a list of bearings (products) that fit his needs

The problem is that

• We have +2048 Models - so facet fields don't work
• Facet terms have only 100 options - some options are missing
• If we get all product id's, it will just give me the values for page 1, so that's not good either

If I could set the facet terms amount from 100 to the top 3000 (for example), I'd get the performance I need (compared to the facet field) and all of the values the customer wants.

Of course I am concerned with performance, but that's what the customer already has on his website and we need to replicate. It serves a specific set of end customers and they are willing to wait an extra second for it.

Any ideas?

BR

Nuno Aguiar

Can you explain your product data a bit - how and where are you storing Makes and Models?

Is it like this?

Product

• Field, Product Name: Bearing 1
• Custom field, Makes: Make 1, Make 2, Make 3
• Custom field, Models: Model 1, Model 2, Model 3

Hi Nicolai,

Here's what we did:

Ecommerce

• (Field) Product Name: Bearing 1

Items

• Product: Bearing 1
• Items List of Fitments
  • Make
  • Model
  • Feature

Because 1 product applies to multiple scenarios, we had to use Items - This also helps the customer populate Fitments (Make + Model + Feature) in a way that makes sense

IndexBuilderExtender

We query the Items through SQL and create custom properties in the index to accomodate the project needs

• Custom document property: Makes
  • String[] of all Makes form the Item list
• Custom document property: Fitments
  • String[] of Concat("Make","|","Model","|","Feature")

Purpose

• This allows us to get a facet to select a Make
• By selecting a Make we were expecting a facet for Fitments to get us a smaller list of options
• Rendering the options, we'd need to filter out options that start by the Make name
  (I know it's weird, but was the only way we found to take benefit from the index - their current website is fast)

Example

• Bearing 1 fits
  • BMW - Series 3 - Wheels
  • VW - Passat - Steering
• The user selects BMW
• He gets presented a list of all BMW Models (+ Feature)
  In this case "Passat - Steering" is excluded by the template
• If he selects "Series 3 - Wheels", he can get to "Bearing 1"
• If we starts over and selected "VW", then he only sees "Passat - Steering" and reaches "Bearing 1" as well

If your curious, this is what we need to replicate http://www.bocabearings.com/bearing-applications/bicycle/bearings-by-model - after you select the brand you get a selection of Models, and finally 1 or more products (bearings) that apply to you bicycle.

Hope you can get a clear picture, otherwise let me know. I'd love to be able to get your input because I am running into very strange scenarios where we need to get creative sometimes :P

Best Regards,

Nuno Aguiar

Hi Nicolai,

Did you happen to understand this issue? We've tried multiple approaches and the customer is becoming impatient (as well as my USA colleagues).

Any help would be appreciated.

Best Regards,

Nuno Aguiar

Yes, but what you describe is not facetting... I could let you return 20000 terms, but it will break your solution and performance... I do not like to make stupid mistakes on purpose.

This is facets - the list of options will be the same as you select criterias - just the counts (and list of products) changes:

• Brand
  • BMW (123 products)
  • VW (321 products)
• Model
  • Series 3 (57 products)
  • Series 5 (100 products)
  • Passat (321 products)

Selecting BMW will give you this:

• Brand
  • BMW (123 products)
  • VW (321 products)
• Model
  • Series 3 (57 products)
  • Series 5 (100 products)
  • Passat (0 products)

In the link you provide, you can do something like this: Show a list of makes (using an itempublisher in DW), then link to a search result of clicking a make (also an itempublisher filtering using that value) and when model is selected, link to the product list using that found model as a parameter.

You probably have all that related data in a very simple data structure. Why no use that to publish Makes, models and fitments - using data lists or something simple? Why first index the values to the products and then reverse it when rendering it?

HI Nicolai,

I see your suggestion but that does not work because the Makes list is already filtered by the ParentGroupID and the ProductType, meaning we need to only show makes for products:

• under a specific parent group
• that are components

That's the main reason I always saw these as facets. Do you have an idea how I could solve this differently?

We also had to implement a "Model search" with facets (check attachment) to mimic http://www.bocabearings.com/bearing-info/bearing-applications- :
(it's the same thing as above but with a search form instead of navigating down some pages)

• Using an index buildex extender we created a field to get only parent group id's that matched a specific parent (grand-parent, grand-grand-parent...) ecommerce group ID
• After selecting it, the user can select a make - the same concept as above
• After selecting the make, the user can select a Model or a Feature (the 2 bottom dropdowns) - the labels change, but that's template "magic".

But I understand your point and I subscribe your statements; There are performance issues and I am very much aware, and so is the customer (we made sure of that). However it's a problem I need to solve in the best way possible.

These US guys give me the greatest challenges and I need to get great solutions. There are always huge amounts of data that keep pushing the boundaries.

(BTW: Hi US guys! )

Best Regards,

Nuno Aguiar

Hi Nicolai,

Did you happen to have another perspective on this? In the meanwhile the customer published the website, so it's not running with Dynamicweb although there are some edge cases where this happens.

Here are the updated URLs to reproduce the scenarios

• https://www.bocabearings.com/model-search
  For the search form where "Applications" facet is a list of subgroups of groupID=L1_BEARINGAPPS (index builder extender)
• https://www.bocabearings.com/products/bearing-applications/bicycle-bearings
  (it redirects to *?ProductType=2 - you can "view source" and scroll all the way down - there's the raw URL there for easier reference. we are filtering for groupID as well)

If I can't/shouldn't do it through facets we might have to do it with SQL (probably indexing some tables).

Best Regards,

Nuno Aguiar

You should use relational data since that is what you are dealing with. It is not facets.

Thanks for the input