Posted by redndahead on February 1, 2012 at 1:27am
2 followers
| Project: | Webform |
| Version: | 7.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
There is a new module called at http://drupal.org/project/list_predefined_options. It is created to make creating predefined options generic so it could possibly be used for webform as well as select fields.
It would be nice if the two could collaborate so eventually list_predefined_options is the preferred method.
@quicksketch Are you interested in this? What do you think this should look like?
I'm willing to write the patches necessary so we can get this to work.
Comments
#1
Make no assumptions on possible solutions ;)
#2
I think that the module you describe could be useful for providing a UI for site-wide custom lists of "things". Re-usable lists of things that could be specific to a website that the user could provide, such as a list of departments, tax brackets or income ranges, age-groups, etc. Basically providing the functionality described in #794564: Prebuilt List Creator. I stated over there that I'd probably prefer this to be a separate module, and it sounds like your module is just the thing.
As for Webform's integration: It's unlikely that we would remove our own hook and support list_predefined_options module exclusively. Actually I'd probably prefer not to build in any integration at all into Webform, but instead have that module implement Webform's existing hook, and just call it's own hook to populate that list (excluding or replacing the ones that overlap). Either way it'd only be a couple ilnes of code to integrate the two modules, but my general philosophy is that the less popular modules implement the hooks of more popular ones (though Webform hasn't strictly adhered to this practice).
#3
I understand not removing your hook to begin with, but what if we do some sort of combining and make it optional. Here is a patch to handle what I am thinking.
#4
#5
Yes exactly, only I think that should live in list_predefined_options() module as list_predefined_options_webform_select_options_info().
#6
I don't plan on adding a conditional in Webform for a brand new module which may or may not prove to be popular in any way. The list_predefined_options module can remove the existing Webform lists through hook_webform_select_options_info_alter() if needed.