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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pwolanin’s picture

Yes, 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.

cpliakas’s picture

Status: Active » Needs review
FileSize
4.76 KB

The 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":

/**
 * Implements hook_facetapi_widgets().
 */
function mymodule_facetapi_widgets() {
  return array(
    'mywidget' => array(
      'handler' => array(
        'label' => t('My widget'),
        'class' => 'FacetapiWidgetMyWidget',
        'requirements' => array(
          'facetapi_requirement_realm_property' => array('element type' => 'links')
        ),
      ),
    ),
  );
}
cpliakas’s picture

FileSize
4.76 KB

Same functionality, modified comments.

pwolanin’s picture

Should 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.

cpliakas’s picture

That's what the $definition is. The idea is to never use facetapi_requirement_property() directly, but to use the wrappers facetapi_requirement_realm_property() and facetapi_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.

cpliakas’s picture

Also... 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:

/**
* Implements hook_facetapi_widgets().
*/
function mymodule_facetapi_widgets() {
  return array(
    'mywidget' => array(
      'handler' => array(
        'label' => t('My widget'),
        'class' => 'FacetapiWidgetMyWidget',
        'requirements' => array(
          'facetapi_requirement_realm_property' => array('element type' => 'links'),
          'facetapi_requirement_facet_property' => array('hierarchy callback' => 'facetapi_get_taxonomy_hierarchy')
        ),
      ),
    ),
  );
}
cpliakas’s picture

Status: Needs review » Fixed

This is a blocker for some other tasks, so I am going to commit so we can move forward. Committed at 40cff37

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.