That doesn’t contradict current state of things. You can transfer your data in DTOs when passing it to render(). One thing is that storing a view file path in DTO doesn’t look right to me since it is mixing two concerns: data and presentation.
Well, to be possible is not the same thing as being encouraged or enforced. My concept enforces a one-to-one relation between view and object. This is again the discussion of how opinionated a framework should be. I have no good answer. But overall I’d say that bigger size, longer time, bigger team --> more opinions needed.
You can transfer your data in DTOs when passing it to render()
Yes, true. I’m doing this already with widgets (Yii 1.1). But my implementation above includes a couple of shortcuts, like the render function, and unpacking the object properties directly into the view (although hackish).
One thing is that storing a view file path in DTO doesn’t look right to me since it is mixing two concerns: data and presentation.
Some people complained about too much magic, the class name automatically being the name of the viewfile. I guess the mapping between DTO and viewfile could be put in a separate class injected to the render object, like
So that depends on the situation. Every team expands on the framework constraints adding their own. That could be in the team rules book.
About your solution, I don’t see what problem it may solve in my projects so it is not useful for me. But, I know that projects vary and some flavor of projects may have problems to be solved by this solution. That’s the reason for not being too enthusiastic to include it into the framework.