Original post from SergeyR at http://drupal.org/comment/reply/551620#comment-4732900
please look at endeca "precedence rules"
as i understood this is a possibility to manage facet dependencies in general case
and in fact the actual dependencies pligins are just limited to parenth's facet that is content type
my vision -it must something like this:
"at least one of the selected content type must be active" >>>"all selected filters type must be active"
or
"all selected value of filters type must be active"second approach just eliminate queries to search server with possible zero count facets -but hard for configuration interface -anyway first approach is working-see next:
i.e. -you have content type (read: value of filter1) " news" with field "date" (filter2) and "goods" (another value of filter1) with "manufacturer" (filter3)
and you have idea to select date as soon as news are selected and to select manufacturer as soon as goods are selected
make dependecies filter1>filter2 and filter1>filter3
as soon as you select any value of filter1 -both filter2 and filter3 will be activated -but if value of filter1 will be news -filter2 will work but filter3 will have zero count and appropriate block will be invisible -anyway the goal achievedPS
sytem must to disactivate children's filters as soon as parenth's filters are disactivated
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | facetapi-round-shape-option-value.png | 90.01 KB | ygerasimov |
| #8 | facetapi-parent-dependency-settings.png | 65.27 KB | ygerasimov |
| #8 | facetapi-1218714-parent-dependency.patch | 3.16 KB | ygerasimov |
Comments
Comment #1
cpliakas commentedSergeyR,
Thanks for bringing up the Endeca use case. Have some questions for you:
Are you saying to have an option to use "AND" logic instead of "OR"?
To my knowledge Facet API doesn't show facets with 0 results, however it is up to the backend to determine which items returned.
I'm not following. Are you saying you are able to achieve this with Facet API's dependency system? Currently Facet API has an option to hide blocks that don't have any facets so I would guess this is achieved automatically?
Facet API works this way.
Thanks for posting,
Chris
Comment #2
SergeyR commentedThank you for attention to my message
First of all I want to highlight that there was 2 separate ideas a little bit mixed:
1.Extend dependency determination (conditions for filters to be queried to search server ) - not just upon content type you have made active before - but rather ANY filters (content type included )
2.!!! to determine dependency in some another way: Parents filter TYPE (not VALUE) (may be few) >>Children filter TYPE
so in this construction "AND" logic may work.
For example:
We have product catalog with next facets: Type of goods, manufacturer, goods properties (dependent on type of goods), product line (dependent on type of goods AND manufacturer)
So the first dependency reflects the fact that some goods property is aplicalable only for determined type of goods
and second - that some manufacturer (not all) have some product lines (i.e quality level) for some type of products (not for all)
determining this dependencies we say that
1Dont Ask user about goods properties until he made the choice what type of products he is interested in
2Dont Ask user about quality level (product line) until he made choice both manufacturer AND product type
simplicity of approach have some weakness -as soon you choose product type -ALL product properties will be queried but only available for concrete type of produsts will be shown
Comment #3
SergeyR commentedEndeca Glossary
precedence rule A trigger that causes dimension values that were not previously displayed to become available. Precedence rules reduce information overload, because the user is not presented with too many, or inappropriate, navigation choices
Comment #4
SergeyR commentedThe same idea -another terminology
http://download.oracle.com/docs/cd/E23095_01/Platform.93/ATGMerchandisin...
This approach limited to the only one parenth
Comment #5
cpliakas commentedAdding to the Contrib component, which means that I am looking for this functionality to be added outside of this module in a separate contrib.
Comment #6
SergeyR commented----------------------------------------
Vision of solution from user point of view
For example i have set of facets :shape,diameter,etc.
First -i want to make dependecy between shape and diameter as parenth and child facets
So i need to have fill the table with 2 columns (parenth and child)
First row i want to add is shape +diameter
Here configuration finished and later you can add more rows
------------
What does it mean this dependency?
It means that facet diameter is being proccessed (inluded in quiery to search server and therefore facet block became visible) ONLY if facet shape is determined(any type of shape is choosen). And
Futhermore became unprocessed as soon as shape became undetermined(choice of type of shape unchecked)
---------------------------------
What does visitor see?
First he see facet block with choice of shape
If he made choice of 'round' -then choice of diameter will be suggested (all round items have diameter value)
If he made choice of 'rectangular'-no choice of diameter willbe suggested(all rect.items have no diameter value)
Then -if visitor deciede to to uncheck his shape choice -he will be back to initial point (even without unchecking choice of diameter value)
----------------------------------------------------------
Its first ,i believe the most simple approach and futher sofistication may be
Comment #7
cpliakas commentedChanging title.
Comment #8
ygerasimov commentedHere is initial patch to support this type of dependency (I named it as "parent").
The idea is following: we have three facets: shape, diagonal and radius. Shape has two options: round and square. If use selected round shape we show radius filter. If user selected square shape we show diagonal facet. We do not show diagonal or radius facets if no choice is done in shape facet.
How to set it up:
1. Add three term reference fields to page, create terms, generate nodes with terms, index them.
2. Add all three facet blocks.
3. Check the value of the "round" option value in shape facet. In my case the value is 16 (see screenshot)
4. Go to dependency settings of Radius facet and set parent facet Shape and value 16 (see screenshot).
Now Radius facet will be displayed only if "round" option is selected in Shape facet. We should also do the same for Diagonal facet and "square" option.
In this way we create parent dependencies and can show some facets only in case specific options selected. This gives much nicer UX in terms of narrowing our results and showing more and more specific facets.
Patch attached.
Screenshots:


Comment #9
cpliakas commentedThe patch in #8 works exactly as advertised. Awesome functionality! Despite the awesomeness, I would actually recommend that this be contributed as a separate contrib. There seems to be a lot of places this module could go, and I think it would be great to have to ability to innovate faster than core. I also think that maintaining as little as possible in core will help the ability to maintain Facet API.
Thanks for the contribution!
~Chris
Comment #10
SergeyR commentedi tested too -everything is perfect ( even cases when child is simulataniously parent for another child)
i see next inprovements for this plugin:
1.separate it from core (agree with Chris)
2.make setting value of parent facet more user's friendly (from list of labels)
3.multiparents setting (with OR/AND condition )
Not specific for this plugin - removing child's query string from URL after parent disactivated
http://drupal.org/node/1374040
i changed my mind -and think priority of resolving it should be higher (new issue to be?)
Comment #11
ygerasimov commentedChris, how you would name this contrib module? I believe it might have some other plugins in the future, so it should be something general. Maybe facetapi_extra or something?
Comment #12
cpliakas commentedYuriy, that seem fine to me. I think common patterns in the community are things like "... Extra", "... Bonus", "... Bonus Pack", etc. so facetapi_extra is right inline with this. I see it as a great module that will allow for some really cool things to be created. I also look forward to the API stress on the core module to see if there are any use cases that cause problems.
Thanks for all of your great work,
Chris
Comment #13
cpliakas commentedMarking the contribution in #8 as RTBC. Once a sandbox project is created I will mark this issue as fixed, then we can track all of the additional use cases illustrated by SergeyR against that project's issue queue.
Comment #14
ygerasimov commentedI have created project http://drupal.org/project/facetapi_extra
Chris, if you will have any other cases of other plugin implementations filed under Facet API module, you can pass them to Facet API Extra module.
I have also added you as maintainer of that module.
Comment #15
cpliakas commentedThanks, Yuriy. I'll take some time over then next couple of days to cross-post some of the Contrib issues ofer to your new project. Thanks for adding me as a maintainer, I'll definitely let you drive it, though :-)
~Chris