At long last, after four years of thought, I have put together a patch to resolve the “more flexible facets” ticket (http://vufind.org/jira/browse/VUFIND-177).
You can see the code here, featuring my back-end code and Chris’ UI beautification:
This adds a few key features:
- Configurable “NOT” facet support in search results (for deleting facets from the list)
- Configurable “OR” facet support in search results (for selecting multiple facets with checkboxes)
- Configurable “OR” facet support for advanced search (to resolve VUFIND-45)
The first two features are off by default, but advanced search facets are now ORed by default (since this seems the more likely desired behavior).
All features are fully implemented for both the Solr and Summon modules. The UI is implemented in all themes, though the jquerymobile theme has only limited support.
If you have a chance, take a look at the patch. I’d be interested in feedback in a few areas:
1.) I had originally thought of creating separate GET parameters for each type of facet – notFilter, orFilter, etc. Then it occurred to me that this is needlessly verbose. Solr already offers syntax for NOT filters in the regular fq mechanism – just prefix the filter with “-“. So I adopted that standard for NOTs, and decided to use “~” for ORs. (A fairly arbitrary decision, but the best single character I could think of). The big advantage to this approach is that earlier versions of VuFind already support NOT in the URL, and now the UI will correctly reflect these types of filters. The big disadvantage is that the tilde OR marker is kind of hacky.
2.) If you have suggestions for better configuration options/layout, let me know; right now most of this is controlled by “exclude” and “orFacets” settings in facets.ini and Summon.ini.
3.) On the backend side, most of the logic is handled by adding an ‘operator’ parameter to the arrays that get passed around to represent facets and filters. The operators then get translated into the appropriate prefixes for URLs and appropriate API parameters for searches when needed. Suggestions for better naming, etc. are welcome.
We can talk about this on the next developers call and decide whether or not to merge to master as-is.