Active
Project:
Model Entities
Version:
7.x-1.0-alpha1
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
16 May 2011 at 10:59 UTC
Updated:
21 Jul 2015 at 14:58 UTC
Jump to comment: Most recent
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 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