Right now, the list of supported handlers names is hardcoded in the module. This means that if you write your own handler, you thus need to hack Views Cloud to make the field appear.
Thanks to Views 2 being properly object-oriented though, that shouldn't be really needed. Attached patch adds a simple check to test if the handler derives from views_handler_field_numeric, and allow it if it does.
With this patch, the special expection for term_node_count could be removed, as term_node_count_handler_field extends views_handler_field_numeric.
(A slightly more general approach might be to drop checking $handler->definition['handler'] completely, and use is_a on all the supported handlers. That's a bit more invasive, so I didn't went for this at first, but could easily provide a patch based on this approach if requested).
| Comment | File | Size | Author |
|---|---|---|---|
| allow_any_numeric_handler.patch | 810 bytes | DeFr |
Comments
Comment #1
DeFr commented(Obviously, another approach is to put in HEAD the commit http://drupal.org/cvs?commit=217596 which was only ever applied to the DRUPAL-6--1 branch which dropped the check completely, but that's /a lot/ more invasive :))
Comment #2
Rino-1 commentedI want to control weight by more than 1 field so I experimented with computed_field and Views_customfield but none of them are recognized even with the patch. I did not try to remove the check completely. Is this anissue for this module or for computed_field/views_customfield?
Comment #3
quicksketchThanks DeFr! This seems like a no-brainer improvement. Committed to HEAD.
@Rino in order for computed or custom fields to work, those modules would need to add separate Views fields for "Numeric custom field" or something, which would inherit from the normal Views "views_handler_field_numeric" class.