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.
There is no reason for wrapping the form logic in a class.
It only makes things harder to understand because it's a rarer pattern and has more (unneeded) complexity.
EntityDefaultUIController is meant to be used for exportable (configuration) entities, which are not the entities we are building in every-day work.
It is enough to just have the admin.inc file with the functions broken out (like Commerce and its contributed modules do)
Comments
Comment #1
fagoImo controller approach makes sense to provide defaults, that an implementing module may override as it is not good if the the implementing module already makes use of the alter hook. The alter hook should be left alone *by default*, so contribs making use of it can build upon the defaults provided by the implementing module.
If that's not what happening here, I'd agree and go with the simple way, i.e. don't use a class.
>EntityDefaultUIController is meant to be used for exportable (configuration) entities, which are not the entities we are building in every-day work.
I'd appreciate a patch contributing another controller, maybe building upon views+vbo to build listings of content-entities ala admin/content.
Comment #2
BarisW CreditAttribution: BarisW commented@bojanz: I really would love to see a simpler example without using the EntityDefaultUIController. A patch would be more than welcome ;)
Comment #3
Anybody