Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
- AllowedValuesInterface documents getPossible*() as being intended for configuring search filters, which for the use case of entity fields, means you don't have a concrete entity you're working with, but are configuring something that might return 0, 1, or N entities.
- Some of HEAD's implementors of AllowedValuesInterface are field type classes, such as ListItemBase and ConfigurableEntityReferenceItem.
- This means you need an instance of a field item (and therefore, an instance of an entity) in order to invoke a getPossible*() method on it.
- If you're configuring a search filter that is specific to a bundle, then you can create a fake entity in order to get the field item object. This is ugly, but possible.
- If you're configuring a cross-bundle search filter (e.g., a Views filter), then to create a fake entity, you need to decide on an arbitrary bundle to use, and the result you get back would be specific to that bundle. We could choose to document somewhere that getPossibleValues() must return the same data regardless of bundle, but the labels returned by getPossibleOptions() should be allowed to vary by bundle, but in a cross-bundle search, you wouldn't necessarily want those bundle-specific labels.
- In core, we've circumvented this problem by not having Views filters for ER fields (the filter can be applied via a relationship instead) and having ListItemBase delegate getPossibleOptions() to options_allowed_values(), which Views can call directly rather than via a ListItemBase object.
- But, do we want to come up with a better pattern for contrib field types to use?
Proposed resolution
- Either decide that what we have in core is ok, and that contrib field types can invent their own delegation mechanisms similar to options_allowed_values(), and Views and other cross-bundle use cases will need to invoke those mechanisms as appropriate on a per-field-type basis.
- Or, come up with a field system API that allows a bundle-independent object that implements AllowedValuesInterface to be retrieved. See #2238085-15: [regression] options_allowed_values() signature doesn't allow for Views filter configuration for one such proposal.
Comments
Comment #1
effulgentsia CreditAttribution: effulgentsia commentedTagging to match #2238085-7: [regression] options_allowed_values() signature doesn't allow for Views filter configuration, since this is a continuation of that original line of work before that issue became more targeted. Note, however, catch's comment immediately following that related to whether this could be done in a way that maintains enough API compatibility to go in after beta.
Setting priority to major instead of critical, since the critical part of that issue was a Views regression from D7 related specifically to list fields, which is addressed in that issue. Providing a unified, cross-field-type API might be nice, but I don't know what would justify that being critical.
Comment #2
xjmComment #3
fagoI do think the current situation is rather sub-optimal and I'd love to see a decent solution to be used that solves the problems outlined here and covers our other use cases on context definitions as well. Therefore, I opened #2329937: Allow definition objects to provide options for the proposed solution.
Comment #4
clemens.tolboomAnother use case would be #2332833: Allow range when editing a number field which could have a
<datalist />element containing key|value pairs.Comment #5
xjmTagging as a priority for a pre-AMS beta sprint.
Comment #6
catch