Spin-off from comment 7 of that issue, amateescu suggested:. In
I also see another option for the UI: have a single "Reference" entry in the main select widget which exposes a secondary list of all possible entity types
That issue has moved in another direction, but I think this idea could be useful regardless, and for more than just the ER field type(s).
If you currently install Drupal HEAD and enable all field type modules, you get 18 options for "Select a field type":
- Boolean - Date - Decimal - E-mail - Entity Reference - File - Float - Image - Integer - Link - List (float) - List (integer) - List (text) - Long text - Long text and summary - Telephone number - Term reference - Text
What if we replaced this with an initial select containing:
- Boolean - Date - E-mail - File... - Link - Number... - Reference... - Telephone - Text...
A top-level selection of "File..." would open up a second Select right next to it containing:
- File - Image
A top-level selection of "Number..." would open up:
- Decimal - Float - Integer - List (float) - List (integer)
A top-level selection of "Reference..." would open up:
- Comment - Content - Term - User (plus others TBD)
A top-level selection of "Text..." would open up:
- List (text) - Long text - Long text and summary - Text
- Especially in the case of the secondary select for "Text...", I think the alphabetical ordering results in an unfortunate order, but let's ignore that in this issue. I also think the "List (*)" labels are confusing, because you're not creating a list, you're creating whatever type is in the parens, and then just restricting the content author to select from a preset list of options, but again, that's a preexisting condition of HEAD that can be discussed in a separate issue.
- Above, I put File and Image into a File group and Term into the Reference group. That's partially based on , though what to do about Term might need more discussion.
- In terms of implementation, my current assumption is that the final selection corresponds to a distinct field type. So to implement the "Reference..." grouping would require that each entity type reference is a derivative plugin (sub-field-type), per . So, the groupings is just a UI suggestion, not something that requires any deep changes in Field API. Perhaps just a hook to allow modules to define/alter the groups.