Closed (fixed)
Project:
Facet API
Version:
7.x-1.x-dev
Component:
Code
Priority:
Major
Category:
Task
Assigned:
Reporter:
Created:
2 Jun 2011 at 16:25 UTC
Updated:
23 Jun 2011 at 02:21 UTC
Jump to comment: Most recent file
The 6.x-1.x version of the module had a "widget requirements" system that filtered a facet's available widgets based on requirements in the realm and the facet. The system worked well but was a bit convoluted, so it needs to be re-implemented in a way that is transparent for developers.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | facetapi-1176814-3.patch | 4.76 KB | cpliakas |
| #2 | facetapi-1176814-2.patch | 4.76 KB | cpliakas |
Comments
Comment #1
pwolanin commentedYes, we really need some version of this so we can contrain the UI to show sensible combinations of widgets depending on the query type plugin, etc.
Comment #2
cpliakas commentedThe attached patch adds a requirement system which should be flexible enough to handle all use cases. It allows the widget to specify requirements callbacks that either return TRUE or FALSE, and there are some default callbacks that allow for simple checks against facet properties and realm properties. If any requirement fails, the widget is not made available to the facet.
For example, the following code would ensure that the widget is only available when the realm's element type is "links":
Comment #3
cpliakas commentedSame functionality, modified comments.
Comment #4
pwolanin commentedShould the facetapi_requirement_property callback get the entire facet too?
Seems like that would allow for more complex checks rather than just passing the options array.
Comment #5
cpliakas commentedThat's what the
$definitionis. The idea is to never usefacetapi_requirement_property()directly, but to use the wrappersfacetapi_requirement_realm_property()andfacetapi_requirement_facet_property()which then pass the full realm / facet definitions as$definitionrespectively.If you are defining a custom requirements callback, the parameters passed to it are
$realm, $facet, and $options, so you should have all the information you need.Comment #6
cpliakas commentedAlso... you can pass multiple requirements callbacks so you can do checks on the properties in both the realm and the facet. For example, if you wanted to ensure the widget is only available to a facet with a hierarchy callback of "facetapi_get_taxonomy_hierarchy" that is in a realm whose element type is "links", you could use the following snippet:
Comment #7
cpliakas commentedThis is a blocker for some other tasks, so I am going to commit so we can move forward. Committed at 40cff37