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

fago’s picture

Imo 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.

BarisW’s picture

@bojanz: I really would love to see a simpler example without using the EntityDefaultUIController. A patch would be more than welcome ;)

Anybody’s picture

Issue summary: View changes
Related issues: +#1158856: Remove custom controllers