Basically, a widget that just renders the viewfile with the same name as the object. Is this a known pattern? Should it be generalized? Pros, cons? Curious if anyone else did this.
The different object classes are saved in a folder together with the widget, so you have:
The use-case is to separate data from HTML. So, if I have widget with three button types, and maybe six total buttons, I can give the widget a list of buttons, and the widget will delegate the correct view to the correct object. An alternative to use class name as view file is to have an object property $viewFile for each object. If I did the render in a view file, I would still need a function to combine the object and its view somehow.
The widget also gives us a folder structure and somewhere to place related objects and views.
That would save you one render call per widget. Not a huge gain considering that there are many widgets that do no view rendering or using multiple views at the same time.
In case all your widgets follow the same pattern it makes sense to have a base class for these.
Yeah, performance is not important here, it’s more a question of code organization.
Yep, I’d like to have a base class, but also a widget that can inherit views. That is, first look for child views, and if there are none with the correct name, check parent folder. Guessing I’ll have to override the render method to do this.