Based on an IRC conversation with merlinofchaos regarding #336450: Signup's views2 boolean filters have terrible UI, we decided the most elegant solution is actually a fix to views_handler_filter_boolean_operator itself:

A) We'd remove the checkbox when configuring the filter entirely.

B) When configuring the filter, we'd use radios for better clarify.

C) With the exposed filter, we'd still use the drop-down select for a more concise UI.

D) We'd introduce a get_value_options() function to the class, to return the array of options to use for either the radios or the select.

E) In the base class, we'd implement that function to just return array(1 => t('Yes'), 0 => t('No'));. However, child classes that wanted more descriptive labels could return stuff like array(1 => t('Open'), 0 => t('Closed'));, array(1 => t('Enabled'), 0 => t('Disabled'));, whatever they want.

Stay tuned, I'm rolling a patch now.

CommentFileSizeAuthor
#1 336531_views_boolean_filter_ui.1.patch3.51 KBdww
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dww’s picture

Status: Active » Needs review
FileSize
3.51 KB

Added benefit:

F) admin_summary() can use the same values, so you don't have to re-implement that in child classes to get consistent labels.

In my testing, this is working very nicely. At most, my child classes now just have to implement get_value_options(), instead of admin_summary() and value_form().

dww’s picture

FYI: I tested this with all the signup filters using http://drupal.org/files/issues/336450_signup_views_filter_ui.3.patch from #336450-3: Signup's views2 boolean filters have terrible UI and everything here is working great.

merlinofchaos’s picture

Status: Needs review » Fixed

Committed. I added a bit to this; the default value_options checks $this->definition['type'] for true-false, yes-no or on-off, similar to views_handler_boolean_field does. That covers the vast majority of the cases.

Status: Fixed » Closed (fixed)

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