Developer forum

Hi Mário

I do not understand the question... Could you ellaborate, maybe with a couple of screendumps?

Thanks, Nicolai

Hi Nicolai,

I've recorded a screencast (http://screencast.com/t/BSPQQagG).

As you can see we get label and value on the FacetOptions, my question is how can we set up a new field on index (screenshot attached) that also retrieves value/label and not just value.

Thanks in advance,

Mário

Ok, so you want to index not the value of the field, but the label... (you cannot have both) ? That is not possible currently.

What is the scenario - why do you need to index the label and not the value? You cannot use that information for anything except searching?

The scenario is:

On the frontend I need to show a dropdown with the color code as value and the color name as Label, but in the index I just have color codes on field (populated by IndexBuilderExtender).

Can I save both and filter by color code? Maybe saving a Dictionary...

Thanks, Mário

Hi Mario

Show them where? In the facets? Because that is what they do already. If you create a facet over that field, the options will contain a value/label collection of the colors.

BR Nicolai

Hi Nicolai,

Let me try to help provide another POV and context:

• Consider a product custom field or product category field of type "List Box" (dropdown) - i.e. Field X
  • Options for Field X
    • Label: A - Value: 1
    • Label: B - Value: 2
    • Label: C - Value: 3
• In the UI you get a dropdown for Field X
• In the Repository we create a facet for Field X, which will give us all available Options as FacetOptions
• The index engine will give me both label and value - this works great

What we are trying to achieve is the same funcionality but through an IndexBuilderExtender.

We understand it only affects the searching, but we already have the logic in place for the product list and detail pages. We just need to extend the documents to allow the facets to reproduce the desired funcionality.

Hope this makes sense.

Nuno

I must be stupid, because in my world that is exactly how facets work... And I have no clue for what reason you need the labels to be indexed. You have still not explained that. The data in the index is shown nowhere... Except facets and there the value will be replaced by the label.

If you are building and IndexBuilderExtender you get the value of the field, and then you can simply look up the label in the DB and index that instead....

BR Nicolai

Hi Nicolai,

I wouldn't be so hard on you :)

Here's are 2 case scenarios:

• Facet for Parent Groups that only list 2nd level groups
  I want to index the ID's so I can get proper URL's submitting &GroupID=X
  In the query we match the GroupID parameter against the ParentGroupID's
  In the facet I don't want to list GroupID, but show the much friendlier Group name
  I guess we could do some matching on the template, but wanted to understand if there was another way to do it
   
• Facet for color picker
  http://screencast.com/t/d2jppzP2r
  We can index/submit a hexcode
  We need to associate a user friendly label (color name) which will be set as a title and/or label, next to the color
  The purpose is to show a hex color next to "Light Gray", "Medium Gray",...

I understand if it's not possible, but at least now you get a clearer picture of what we need to achieve. The hope was that we would not have to do a lof ot logic on the template to have this label+value match.

Best Regards,

Nuno Aguiar

Hi Nuno

That's the thing. In my world it is already possible without any customisation.

If you create a facet for the custom color field where the hex is the value and the label is the label, when you render the facet, in the options you get a list of hex codes and their labels and if you want you can just render them like a color selector...

Hi Nicolai,

I see your point, so here's the problem:

• The customer has 4 fields that go hand in hand with a variant
  i.e.: VO1 must always match Hex color #660000 and match Color "Dark Red" and match Generic Color "Red"
  • Because this is very error prone, we are moving to Variant properties
• ​Variant properties are not indexed so we are using the IndexBuilderExtender for it

If we could find a way to do this through an IndexBuilderExtender, we would apply the same piece of code for other custom and wacky queries we need sometimes :)

Hope this make sense?

Best Regards,

Nuno Aguiar

Hi Nicolai,

Did you get a chance to see my last reply? Does it make sense now? Is there a way we could do this?

Best Regards,

Nuno Aguiar

Hi Nuno

No, I do not get it... But if you just showed me how you want it to look and work, I might be able to help you out.

Hi Nicolai,

Sure let me know when we can meet. And here's bit more info to help us when we meet

• The first attachments shows the expected outcome - Group facet
  • In the facet we select GroupIDs
  • In the output we get the GroupIDs as value and the Group names as label
• In a specific project we had to develop an IndexBuilderExtender to
  • Get the ParentGroupIDs (and ParentGroupNames)
  • Remove all values except if they were (direct) childs of Parent Group "Applications"
  • We wanted to develop something else to get the same behavior of the Group facet
  • Instead we had to do it on the template
• In another project we had to use variant properties and had to develop an IndexBuilderExtender to index all variant properties on the document
  • We have to use variant properties per the customer's request
    (so she does not have to manually map variant X to custom field Y)
  • That's straight forward, but now we need to have 1 facet where
    • "Generic Color Code" is the value - so we can paint a square with that hex color
    • "Color Title" is the label
  • If we could assign that "dictionary" (value + label) on the IndexBuilderExtender, we'd get the same behaviour as the Group Facet
  • Instead we had to do it on the template

BTW: I've put this in an unordered list, but the css styles is not showing it. Would have helpded with reading the issue :P

Hope this helps clarify, but I'll be happy to meet with you and show you.

Best Regards,

Nuno Aguiar

I've not been this confused since the first time I fell in love with a girl...

But you basically want to render a color in the facets called "RED" and use its property value "#ffff00" to apply a red square?

If you create a facet over the variant, i.e. color, when you render the options for it, you get all the tags for the variant including property values. It makes no sense at all to index those values since you have a 1-1 relation between the variant id and the properties. Same goes for groups and manufacturers...

See my dumps...

Hi Nicolai,

I laughed until I cried when I read the beggining of your previous reply 

I flagged this thread until I found the proper words to get back to you, and I got lucky here - http://doc.dynamicweb.com/forum/development/facet-template-extender?PID=1605

The ValueMapper addIn is what I was looking for too. If you can make it work in the DW8 branch would be great for us too.

Best Regards,

Nuno Aguiar

Hi Nuno

Ok - now I also understand the question then. But all your examples during this thread is already supported (and you wrote you want to index labels??), that is why I am super confused. You need something in the case where you DO NOT have a variant, a groupid, manufacturer, custom select field etc. Because those values are already matched to an appropiate label when rendered. So it is for situations where you have custom (text) fields with values you want to translate into better labels...?

That would make sense - and also a generic version where you can add labels for values. Which, by the way, can already be accomplished using @Translate tags in your facet template.

Hi Nicolai,

Yes, I see why you were confused. The Value Mapper is the answer for us.

We did use the @TranslateTags approach in some projects, but sometimes the labels already exists elsewhere (from integration most of the times), so the Value Mapper is perfect to match the indexed value with a list of labels we get from SQL. This will be great to have :)

Best Regards,

Nuno