Allow the values of list field types to be pulled from a view.

[klonos]

I am in need of a way to have the results of a view to be rendered as a select list (drop-down preferably) and that to be a field in a content type. It seems that I'm not the only one looking for something like that:

entities - Populate a drop down select list with the results from a view with entity reference relationships - Drupal Answers

...although that thread is specifically about entity reference fields, in my case I simply want to use the content type as the means for exposing the options of this select field to specific users and allowing them to edit the list. But this can be on our roadmap because we plan to have references in core anyways AFAIK.

I thought that this could perhaps be implemented as a views display (like we do for views-generated blocks) and then have this as an available option to select the field settings "Allowed values list" (mockup):

I looked in d.org for any related modules. Here are my findings:

Entity Reference View Widget (screencast to see it in action)

This module provides an advanced Entity Reference widget that uses a view embedded in a modal dialog for selecting items. The view can be paginated and have exposed filters.

...not exactly what I was after in my specific use case because it uses a modal while I was after a drop-down select list, but very interesting nevertheless.

EntityReference Dynamic Select Widget

This module provides an advanced Entity Reference widget that uses a special select control for selecting items. The select form element options are generated by a view with a special display. This special display strips out any HTML in the view's row results so that it can be used as select options.

This one renders the view results as a drop-down and also optionally has an AJAX filter for the values of the list (don't really care about that feature in my use case, but thought it's worth the mention)...

The widget filter text box can be used to limit the number of options using view's filters selected in the widget settings. When the widget button is clicked, an AJAX call passes the filter text to the selected view's filters and the select form element is refreshed with the view results.

Here's what it looks like:

Thoughts? Core-worthy you think?

[MrHaroldA]

Core-worthy you think?

Yes, but it has to replace the taxonomy widget too, as that is also "viewable". The result must/will be a standard dropdown, which could be extended using something like Select2 #459.

The question is what will be saved to the database. The ID of the entity? ID and Revision ID? Numeric ID? ...

[klonos]

I changed the issue title to be more generic and cover all cases. So, the idea is to have the values for list fields be pulled from a view that the user specifies instead of having to type the values. The widget for these can be then rendered as a select list, an auto-complete field, a drop-down menu, a set of checkboxes or radio buttons. The key here is where the values are pulled from.

...but it has to replace the taxonomy widget too...

Not sure how this would apply to taxonomy because that is a different field type (reference). In these fields, the results are pulled from vocabularies - not views. In order to make the implementation I am suggesting here apply to these as well (in a low-level, API style), I guess we'd have to somehow have a view automatically created for each vocabulary so that we can have the terms in a views-generated list that could then be passed as values for the term field widget. The alternative would be to convert vocabularies to be views of terms. But that seems like an API change to me. Anyways, my point is that this would be a different can of worms.

The question is what will be saved to the database. The ID of the entity? ID and Revision ID? Numeric ID?

I'd say we could let that be a setting in this specific view display type. Perhaps have it always default in the entity ID but also allow advanced users to select any other field that might be in the view or available for the entity in general. Since we can have fields in the view, but exclude them from display, in the same manner we could have one such field be excluded from display and used as the value to be stored in the db.

The simplest case though would be always save the node ID in the DB and use whatever field the user wants for widget value.

[ghost]

My thinking is this may be better as a contrib module, but we can see what others think...