As it currently stands, views_handler_filter_in_operator only supplies default Yes/No values, and requires module writers to subclass it in order to provide their own options generator.
This is done in order to prevent storage of such values in the database. An alternative is to provide a way to simply pass a callback generating these values, by declaring its name as an options callback parameter in the field definition, which can either be a string containing the name of a function, or a (class,method) array, as used by call_user_func().
The suggested patch includes this.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | in_operator.patch | 1.38 KB | fgm |
| #1 | in_operator.patch | 1.31 KB | fgm |
| views.patch | 1.22 KB | fgm |
Comments
Comment #1
fgmEeek, wrong patch submitted.
Comment #2
dwwcool, thanks. in principle, i support this feature. in practice, do we really need to do this in a single line? ;)
I mean, I can read it, and I'm sure it works, but geeze... can't we split this up into a few more lines to make the logic of it more self evident? ;)
Maybe Earl likes this kind of thing, but personally, I've never understood the appeal of "it's a tiny patch -- only 1 line! (with a ternary operator and a side-effect assignment nested inside a conditional clause)..."
Comment #3
fgmOK, back to my original version, then. Maybe my APL background shows too much :-)
Comment #4
merlinofchaos commentedCommited to 2.x and 3.x