Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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 CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: cpliakas commentedSame functionality, modified comments.
Comment #4
pwolanin CreditAttribution: 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 CreditAttribution: cpliakas commentedThat's what the
$definition
is. 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$definition
respectively.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 CreditAttribution: 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 CreditAttribution: cpliakas commentedThis is a blocker for some other tasks, so I am going to commit so we can move forward. Committed at 40cff37