Allow pluggable select list values

Thanks Crell, this looks like an excellent suggestion! For everyone that's really wanted it, this could be a gateway to #151603: Can I put options in a select field from a database query?. Really I prefer to avoid ever giving users the ability to enter PHP code (oh the results of "Additional processing" and "Additional validation" scare me...) so this would be a great compromise that would allow any user to create their own list through PHP code but not have to expose that to the end user. Plus Webform could ship with a few common lists like Countries and States since I bet those are used rather frequently.

There's already a handbook page on Countries and States as piped lists: http://drupal.org/node/221490

After discussing with quicksketch in #drupal, this should probably be called from _webform_select_options .

subscribing!

What's the status of this? Is there any progress? I'm interested in this feature and can help implementing it.

Subscribing.

Yes please. I'm currently using the Webform Select module, but that prevents the use of %get to set the default selection, which is less than desirable, and this is not something that I need an admin interface for anyway.

So, finally, a year later. I got this implemented this weekend in the 3.x version. This patch mostly follows Crell's specifications in the original description, though some things are slightly changed:

- I renamed the property "options" to "options callback", to match the menu system and image.module in Drupal 7.
- I didn't implement the "form" (or likely "form callback") part, mostly because this would have involved a lot of extra implementation and we didn't need it for any of the default lists Webform is providing. Modules can still hook_form_alter() these items in anyway.

This should work with or without the Options Element module, and after selecting a pre-defined list, it loads the list of items into the textarea of options, but disables the textarea so these items may not be changed. It does not support using a PHP textarea for specifying options, though it could be extended fairly easily with a few more changes and then integrated with http://drupal.org/project/webform_php.

Nice feature addition! So every select field now has a "Load a pre-built option list" option, allowing to prepopulate the Options text area with either 'Days of the week', 'US states' or 'Countries'.

I think it should be documented that the list of countries in Drupal 6.x is only available when the Country codes API module is installed.

Works Great! Brilliant!

The attached patch against DRUPAL-6--3 adds a list of currencies, as long as the Currency API module is installed and activated.

Let's open new issues for new lists. I moved your patch to #766102: Add Currency pre-defined select list.

quicksketch: Would you consider modifying the select_options_info() hook to allow the usage of arguments for the options callback?

So you would have something like

function hook_webform_select_options_info() {
  $items = array();

  $items['days'] = array(
    'title' => t('Days of the week'),
    'options callback' => 'webform_options_days',
    'argument' => 'example',
    'file' => 'includes/webform.options.inc',
  );

  return $items;
}

I ask because I would like to populate the select options list with Views. I have an admin page where a user can specify which Views they would like to show on the select list options in a Webform. In my implementation of webform_select_options_info(), I loop through those Views and build $items based on that information. The problem is that all items share the same option callback, and without passing an argument to the callback, there is no way within the option callback to know which View data to return.

function webformselectviews_webform_select_options_info() {
        // Get a list of View IDs that are defined in admin/settings/webformselectviews
	$view_ids = variable_get('webformselectviews_views', array());
	$items = array();
	$sql = 'SELECT vid, name FROM views_view WHERE vid = %d';

	foreach ($view_ids as $view_id) {
		$result = db_query(db_rewrite_sql($sql), $view_id);
		while ($view = db_fetch_object($result)) {
				$items[$view->name] = array(
		 			'title' => $view->name,
		 			'options callback' => 'webformselectviews_options',			
		 		);
			}
		}
  return $items;
}

What I would need is a way to specify an argument (in this case, the View name) to webformselectviews_options, so that the options callback function returns data appropriate to a given view.

My options call back would look like:

function webformselectviews_options($argument = NULL) {
		$view = views_get_view($argument, true);
		$view->execute();
		$items = array();
	
	foreach ($view->result as $item) {
	  $full_node = node_load($item->nid);
	  $items[$item->nid] = $full_node->title;
	}
	return $items;
}

The alternative for what I'm trying to do is to set a limit to the number of Views that can be used as pre-selected options in Webform, and define a unique option callback for each one of them, but that would be awkward and not flexible.

What do you think?

Yes I'd definitely like to add Views support, though I'm not sure how to handle arguments or any other additional fields for inputting various options. My initial attempt at adding this functionality I actually passed the entire component to the options callback. This made it so that you could add any fields you wanted or adjust your options based on anything in the component. Unfortunately this was a problem when creating a new component and previewing the options, since the component hasn't yet been created. I'm sure there's some way around this technical problem, it will just take more effort.

So yes, I'd like to add the functionality you've described (maybe not exactly how you've recommended implementing it) and we should followup in a new issue to work on adding it. I've also got some other ideas, like how to filter down the list of views that may be available. Or even just inherently making certain views directly available from the current drop-down select list of predefined options.

I've added my thoughts about Views integration over in #767290: Allow Views to be used as pluggable select list values, let's continue there.

so do we have a way to pass arguments?

so it looks like 'options callback' is how you specify the callback, there is kind of a cheap way to pass arguments through the 'options_source' parameter.

I made a proof-of-concept module that works pretty good. It will create a pre-built list for every vocabulary on the site. I suppose I could publish it if you think it's any good, please advise.

Here's the module code btw:

http://codeviewer.org/view/code:1270

Please open a new issue. for further questions, this feature request is complete. I think 90% of all requests could be met by implementing #767290: Allow Views to be used as pluggable select list values.

I'm aware of using views for options list. However, I find useful to be able to use php to populate those lists. However, the actual code has a bug when adding options arguments to the hook function. I attach a patch to fix it.

Besides that, whenever you use an argument in your callback function, your argument will be the fourth one. This should be explained in webform_hooks.php somehow. Taking the example in webform_hooks.php and changing it to use an argument:

function hook_webform_select_options_info() {
  $items = array();

  $items['days'] = array(
    'title' => t('Days of the week'),
    'options callback' => 'webform_options_days',
    'options arguments' => $my_argument, //add the argument here
    'file' => 'includes/webform.options.inc',
  );

  return $items;
}

The callback declaration should be, in this example, as follows:

function webform_options_days($component, $flat, $filter, $my_argument) {
.....

By the way, I could not attach the file as .patch but .txt (?)

Thanks for the patch Robert. Opening a new issue would have been a better approach for filing this bug report (you shouldn't mix bug reports in with feature requests, it makes searching difficult).

Thanks jaykali, your module works very well!

@robertgarrigos: I couldn't find any possible reason for your patch. All it does is rename the otherwise unused variable $arguments to $options_args, which doesn't make any difference in functionality at all. Please open a new issue for any further bug reports on this, as this "feature request" was finished a long time ago.