Instead of relying on the select_or_other field formatter, I think we can use a field's default formatter (and settings) and just modify the values/markup for the select options as needed.
This patch has only been very lightly tested and the existing select_or_other formatter hasn't been removed from the code. Doesn't handle available options via PHP and keys for available options have to match more closely than in the form api (-100 as a key for a decimal field works in the form api, but this patch requires the key to be set as -100.00 to match the field storage settings).
| Comment | File | Size | Author |
|---|---|---|---|
| select_or_other-defaultformatter-1.patch | 2.48 KB | tauno |
Comments
Comment #1
danielb commentedYou sound like you know a bit about this!
Can you elaborate a little more on the pros and cons, if those were indeed cons that you were implying?
Can I update the available options code with some of the logic out of select_or_other_field_widget_form_prepare_options() e.g. to handle the PHP?
Do you know what I can remove because of this patch?
Also the way the field integration is done is that it is specifically handled for 'text', and the numeric ones, which makes it a bit restrictive. Taking the formatter idea further do you have any idea how I could generalize the functionality as a multiple value widget for any field? I got some doubts as to whether I can, since the 'list' module specifically handles the field types as well. And the idea might just not jive with many field types.
I also see your project "#states or". I would like to remove the custom js from this module and replace with #states, and hopefully open up the possibility for more flexibility, but I haven't really thought it through. Any opinions on that?
Comment #2
tauno commentedI actually ran into trouble with the approach I posted above and with a third approach as well where I modified the select_or_other formatter to pull in the the formatter settings from the default formatter for the field type as the select_or_other settings and then use those settings for the user entered value.
Ultimately the problem I ran into was with Search API. I didn't see a way of modifying the facet_api callbacks based on a field's widget.
I think using #states should work for this module, but I haven't looked at the js yet. Other than the API docs, rfay's post http://randyfay.com/states is helpful.
I'll take a look at this again when I have a bit more time.
Comment #3
danielb commentedOK cheers for the feedback.
Comment #4
danielb commentedThis isn't going to happen is it? I get the feeling Field API is too inflexible to do anything with any sort of abstraction.
Comment #5
danielb commentedI'm closing this issue. I was excited about it though, so if you can make it happen please reopen.