It would be nice if it was possible not only to specify an options callback for views_handler_filter_in_operator, but also options arguments that are passed to the callback.

In my specific situation, I want the callback to be a reusable caching wrapper around the real callback, like this in my.module:

function my_options_daily_cached_callback($callback) {
  $today = date_make_date('now');
  $today->setTime(0, 0, 0);

  $cache = cache_get($callback . '_daily');

  if (!$cache || $cache->created < $today->format('U')) {
    $options = call_user_func($callback);  
  }
  else {
    $options = $cache->data;
  }

  return $options;
}

function my_options_callback() {
  // expensive SQL query here that can have different results each day
  // $sql = ...

  // build options from query results
  // ...

  return $options;
}

In my.views.inc:

function my_views_data_alter(&$items) {
  $items['node']['nid_my_options'] = array(
    'title' => t('Nid my options'),
    'filter' => array(
      'field' => 'nid',
      'handler' => 'views_handler_filter_in_operator',
      'options callback' => 'my_options_daily_cached_callback',
      'options arguments' => array('my_options_callback'),
    ),
  );
}

Patch for the 6-3.x branch attached that implements the necessary 'options arguments' handling for the code example above in views_handler_filter_in_operator.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Cyberwolf’s picture

Code example above was missing a crucial part with cache_set() call:

function my_options_daily_cached_callback($callback) {
  $today = date_make_date('now');
  $today->setTime(0, 0, 0);

  $cache = cache_get($callback . '_daily');

  if (!$cache || $cache->created < $today->format('U')) {
    $options = call_user_func($callback);
    cache_set($callback . '_daily', $options);
  }
  else {
    $options = $cache->data;
  }

  return $options;
}
Cyberwolf’s picture

Status: Active » Needs review
dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Code looks fine. I'm wondering whether this could use used something in views to reduce a bit of code.

merlinofchaos’s picture

Status: Reviewed & tested by the community » Needs work

This option (and it looks like the 'options callback') needs to be documented in the doxygen for this handler.

Cyberwolf’s picture

Ok, I will take care of that merlinofchaos and will post a new patch soon.
Thanks for the feedback.

Cyberwolf’s picture

Status: Needs work » Needs review
FileSize
1.52 KB

Attaching the new patch. I added class-level documentation, under "Definition items:".

bojanz’s picture

+++ handlers/views_handler_filter_in_operator.inc	13 Oct 2010 12:49:45 -0000
@@ -5,6 +5,8 @@
+ * - options callback: The function to call to generate the value options. If omitted, the options 'Yes' and 'No' will be used.

How about making this "The function to call in order to generate the value options.", and putting the next sentence (If omitted...) into the next line?

Let's get another opinion and then finish this.

merlinofchaos’s picture

bojanz' wording correction makes sense to me.

merlinofchaos’s picture

Status: Needs review » Fixed

Committed to 3.x for D6 and D7 with bojanz' wording change.

Status: Fixed » Closed (fixed)

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

cafuego’s picture

Version: 6.x-3.x-dev » 6.x-2.x-dev
Status: Closed (fixed) » Needs review
FileSize
1.36 KB

This is an exceedingly useful addition to help users not have to create callback functions on the fly if they have a lot of different option lists to generate.

Attached patch applies to 6.x-2.x. Only the line numbers have changed.

MustangGB’s picture

Status: Needs review » Closed (won't fix)