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.We have a thousand-and-one situations in which we need options lists of entities of a particular type, such as for form select elements. We currently have functions or methods per entity type, but let's provide an easily reusable method for developers to do this.
An alternative might be to add a static method to EntityInterface and provide default implementations in the base class(es), so entity types can override their 'list labels'. Currency has quite a few config entities with identical names, because those are currencies that in real life have the same names. There are four different Zimbabwean dollars, for instance. Were someone to build an entity type that references real-world people, they would run into the same problem.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | drupal_2111341_1.patch | 2.01 KB | Xano |
Comments
Comment #1
XanoComment #2
tstoecklerSeems we should also test that the options are actually returned correctly for a valid entity type?!
Missing newline. More importantly, it seems this class isn't actually used below?
In general I'm not sure adding this is a good idea. For nodes, calling this on a medium to large site, will try to load *all* nodes, so it will easily crash your site.
So I think we should find some way to only add this for config entities. A static method sucks, though, because doesn't have (clean) access to the storage controller or anything.
Maybe this could also use the nifty iterator @dawehner is doing at #2098197: Add getAllRoutes() method to RouteProvider , but maybe that's overkill
Comment #3
XanoI should have mentioned that the patch was mostly a proof of concept, especially because @dawehner and I had no idea where to best put a method like this.
No idea how that got there. I blame PHPStorm.
Another idea I had was to add this to the list controller, as it essentially returns a list of entity data. We can provide a default implementation in EntityListController, but let specific entity types override the behavior.
Comment #4
tstoecklerYes, I think that makes sense. Can we make it ConfigEntityListController then, please, per the above? I realize that in principal nothing will stop you from having 10,000 content types on the page so even for config entities it *might* be a problem, but it's a much thinner use-case than having 10,000 nodes.
Comment #5
tim.plunkettIn that case, what problem are we solving? List controllers are swappable, so those calling a function like user_role_names() won't be able to use this directly.
Comment #6
Xano@tstoeckler and I discussed the feasibility of instead of letting list controllers just build options, make them build the entire form element used for selection, so content entity list controllers can use autocomplete for performance reasons, and config entities can use select lists. @amateescu overhead us and pointed us to #1959806: Provide a generic 'entity_autocomplete' Form API element, which tries to do a similar thing, but his starting point was Entity Reference, whereas ours is the entity system. If ER becomes required, then we can easily make core use its widgets instead of developing custom solutions per entity type, like we do now.
They are, but adding the method to EntityListControllerInterface ensures that we can always fetch a selector. Swappable list controllers will then be an advantage, because it will allow developers to use a different selector.
Comment #8
Xano#1: drupal_2111341_1.patch queued for re-testing.
Comment #9
Xano#1: drupal_2111341_1.patch queued for re-testing.
Comment #17
BerdirClosing this, nobody seemed to be interested in this and I agree that for most entity types, promoting such a use is a bad iea.