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.
Comment | File | Size | Author |
---|---|---|---|
#1 | 336531_views_boolean_filter_ui.1.patch | 3.51 KB | dww |
Comments
Comment #1
dwwAdded 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().
Comment #2
dwwFYI: 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.
Comment #3
merlinofchaos CreditAttribution: merlinofchaos commentedCommitted. 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.