ZF view coupling
Moderator: General Moderators
ZF view coupling
I've read some bad things about ZF and view coupling in the controller part. But you can set view integration off. Opt-out instead of opt-in. They probably did this so you have a basic functional program ready. I'd like to discuss why this opt-out solution is so bad.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: ZF view coupling
I think combining the View and Controller into the same file for simple things makes a lot of sense in PHP. There could still technically be separation of they are coded carefully -- different methods for example. Obviously reuse is lost, but in simple cases there is very little reuse possible.
I think a better question is not what ZF got wrong, but what ZF and other frameworks don't get right. The View system in ZF is screwy. It does not encourage separation. And if you look into the code, the more features they have added the more tendrils tie the code back to the controllers. There is something wrong at the core of the design.
So what does a design that gets the View right in PHP look like? Anyone have examples from a framework that you think gets it right?
I think a better question is not what ZF got wrong, but what ZF and other frameworks don't get right. The View system in ZF is screwy. It does not encourage separation. And if you look into the code, the more features they have added the more tendrils tie the code back to the controllers. There is something wrong at the core of the design.
So what does a design that gets the View right in PHP look like? Anyone have examples from a framework that you think gets it right?
(#10850)
Re: ZF view coupling
I've read your reply about the problem here (viewtopic.php?f=19&t=81983). So it seems the problem is not withing the view class but the hard-coded support for the view in the controller (actually all front-controller classes) if I understand that response correctly.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: ZF view coupling
If you are referring to the last post it was more a comparison -- with some commentary. I would imagine with ZF that once they started down the road of $controller->render() then it was easy to keep bolting on new functionality because you already have the coupling in place. There is a lot of code there and it keeps growing.
That said, I don't know if the ZF View class is that good either. Given the fact that they had to go outside to implement layouts indicates that it may not be the best design.
Conversely if you try to keep on the low coupling path then you have to redesign more to maintain it. We are currently discussing this exact subject for the Skeleton framework. It is a difficult design problem to solve well. If you or anyone else is interested in this kind of MVC stuff, we need people.
That said, I don't know if the ZF View class is that good either. Given the fact that they had to go outside to implement layouts indicates that it may not be the best design.
Conversely if you try to keep on the low coupling path then you have to redesign more to maintain it. We are currently discussing this exact subject for the Skeleton framework. It is a difficult design problem to solve well. If you or anyone else is interested in this kind of MVC stuff, we need people.
(#10850)
Re: ZF view coupling
I think they have the viewrenderer plugin in the controller package because they wanted a working application out of the box, not one where the action controller has to initiate the view manually. The viewrender seems like something that falls between the controller and the plugin. It doesn't seem to have much use when you wouldn't want to have the option to connect with the view by default. If that's indeed the main reason for its existence I'd leave it out. Which leaves it to the action controller to get a view part somewhere. The question then becomes how that is done best.
Options I see now:
-bootstrap sets it in registry or similar object and actioncontroller uses that
-actioncontroller instantiates it manually
Not every action controller might need a view though. That leaves option 2. Less user friendly, very modular.
Options I see now:
-bootstrap sets it in registry or similar object and actioncontroller uses that
-actioncontroller instantiates it manually
Not every action controller might need a view though. That leaves option 2. Less user friendly, very modular.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: ZF view coupling
A strange thing I noted about ZF is the ViewRender reduces functionality yet adds more code. Seems the wrong way around to me.koen.h wrote:I think they have the viewrenderer plugin in the controller package because they wanted a working application out of the box, not one where the action controller has to initiate the view manually. The viewrender seems like something that falls between the controller and the plugin. It doesn't seem to have much use when you wouldn't want to have the option to connect with the view by default. If that's indeed the main reason for its existence I'd leave it out. Which leaves it to the action controller to get a view part somewhere. The question then becomes how that is done best.
But you still need to set it. And if your want granularity then you are just moving the setting from the controller into config -- which is just overhead really. If you are talking about layouts then that can be central, but the controller still needs to set something, whether automatically or manually.koen.h wrote:-bootstrap sets it in registry or similar object and actioncontroller uses that
You probably needs this option whether you have some automatic system. A separate question is how friendly, easy and powerful is the manual ability?koen.h wrote:-actioncontroller instantiates it manually
If it generates any response to the browser then it has a View. Even with "just a template" there is code to render that template and somewhere echo it.koen.h wrote:Not every action controller might need a view though.
I am not sure. It seems like part a naming issue and part and assembly issue. Here are some permutations:koen.h wrote:That leaves option 2. Less user friendly, very modular.
- View/Template has the same name/position as the controller or controller/method, so you can just say getView() and the framework know what to do.
- View/Template has a different name/position as the controller or controller/method, so you say getView('foo')
- View is complex so you need to do something like:
Code: Select all
$menu = getView('menu');
$view = getView('foo');
$view->attach($menu);
$view->render();(#10850)
Re: ZF view coupling
This getView() would be a an action controller method, right? Then you'd couple the view to an action controller. Maybe less references to it than in the ZF but it's there nonetheless.arborint wrote:
- View/Template has the same name/position as the controller or controller/method, so you can just say getView() and the framework know what to do.
- View/Template has a different name/position as the controller or controller/method, so you say getView('foo')
- View is complex so you need to do something like:Code: Select all
$menu = getView('menu'); $view = getView('foo'); $view->attach($menu); $view->render();
edit: if it's an action controller method, you would also restrict it to actions that extend the ActionController class (though maybe that's what you planned anyway).
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: ZF view coupling
I was really just using that as an example that you would get it from somewhere...koen.h wrote:This getView() would be a an action controller method, right? Then you'd couple the view to an action controller. Maybe less references to it than in the ZF but it's there nonetheless.
As far a coupling ... just because the Controller can load the View does not mean they are coupled. If the View does not need the Controller to do its job then it is independent -- regardless of how it was loaded. I guess the next level would be if the Controller loaded and initialized the View. Then in order to get a useful View you need the Controller. Still not code depenedency.
Yes, but it would not necessarily restrict if the loader was a convenience method and you could still load the View yourself.koen.h wrote:edit: if it's an action controller method, you would also restrict it to actions that extend the ActionController class (though maybe that's what you planned anyway).
The design issue we are struggling with in Skeleton is assembling Templates/Views in a hierarchy (often called layouts).
(#10850)
Re: ZF view coupling
If I change a class and as a consequence have to change something in another class because of that, they don't seem independent to me. Even if the second class would still work without change. For example let's say that I change the name of my view class, then everywhere I'd have to update the name of it is one place too many. It's maybe more of a library than a framework approach.arborint wrote:I was really just using that as an example that you would get it from somewhere...koen.h wrote:This getView() would be a an action controller method, right? Then you'd couple the view to an action controller. Maybe less references to it than in the ZF but it's there nonetheless.
As far a coupling ... just because the Controller can load the View does not mean they are coupled. If the View does not need the Controller to do its job then it is independent -- regardless of how it was loaded. I guess the next level would be if the Controller loaded and initialized the View. Then in order to get a useful View you need the Controller. Still not code depenedency.
What's wrong with the zend layout approach?The design issue we are struggling with in Skeleton is assembling Templates/Views in a hierarchy (often called layouts).
Re: ZF view coupling
arborint, you said you need people for your Skeleton framework. Could you elaborate?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: ZF view coupling
Like most projects we don't have enough time to do everything that needs to be done. And frameworks are a more difficult design challenge than most projects because it is like balancing the designs of a bunch of project together. Most of the work is actually design discussions to distill an elegant solution. The code is usually pretty small if the design is good. I described a little about how the MVC compares to ZF here: viewtopic.php?p=457667#p457667.pytrin wrote:arborint, you said you need people for your Skeleton framework. Could you elaborate?
If you are interested please PM Jcart or me. Everyone involved has a major impact on the design and code. Our design discussions look like this: viewtopic.php?f=19&t=80191. If you have an interest in controller frameworks, and the code looks interesting -- then please get involved. There is a lot to do. We are working toward a first release, but the framework is usable now.
The code is at: http://code.google.com/p/skeleton/. The Subversion repository is obviously the latest; the download is a month or so old.
PS - Your interest in Models could be of great help. In fact, your Techfounder_Db_Model class is almost exactly what we have been discussing for our base Model class (you'll like our Filters and Rules better
(#10850)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: ZF view coupling
Right, but if all controller does is provide a shortcut View loader that is not exactly a dependency. If that was the only way to load views maybe ... Or if the Controller instantiated the View and it was otherwise ususable -- that would be a dependency.koen.h wrote:If I change a class and as a consequence have to change something in another class because of that, they don't seem independent to me. Even if the second class would still work without change. For example let's say that I change the name of my view class, then everywhere I'd have to update the name of it is one place too many. It's maybe more of a library than a framework approach.
Good question. I think the ZF stuff is very good. My criticisms of the Layout code would be mainly be all the wiring code that I discussed above. Just take a look at the _initPlugin() method to get an idea if the dependencies. The class itself is mainly wiring and if you look at the examples this ends up pushing a lot of what I consider View code into the Controller.koen.h wrote:What's wrong with the zend layout approach?
(#10850)
Re: ZF view coupling
I think that what they do in the _initPlugin() isn't that bad. A person decides the use the layout within the mvc and they plug it in the frontcontroller. I don't see how they could have done that in a better way. Maybe that it has to be done with the help of the plugin.arborint wrote:Good question. I think the ZF stuff is very good. My criticisms of the Layout code would be mainly be all the wiring code that I discussed above. Just take a look at the _initPlugin() method to get an idea if the dependencies. The class itself is mainly wiring and if you look at the examples this ends up pushing a lot of what I consider View code into the Controller.
Yesterday I was thinking about my ideal setup. It would consist of 3 phases: library->framework->application. Taking the ZF as an example; the zf library would consist of all components you now see in the framework, only there's absolutely no reference to another components class (how I define 100% decoupling). The second phase consists of creating a framework out of that: a structured unit that allows for rapid application development. The third phase are the actuall applications.
Most frameworks skip phase 1. They continue adding functionality to the framework and after a while it get's a mess.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: ZF view coupling
I would prefer to have it all in the View ... or at least confined to the Action Controller. I think there are cleaner ways to do it than that.koen.h wrote:I think that what they do in the _initPlugin() isn't that bad. A person decides the use the layout within the mvc and they plug it in the frontcontroller. I don't see how they could have done that in a better way. Maybe that it has to be done with the help of the plugin.
Absolutely! That is what we are trying to do in Skeleton. In fact, within our "framework" layer we have some decoupled layers as well. For example, the Front Controller can dispatch plain objects as Action for the simplest level. Or action can inherit the Action Controller class and get Helpers, forward, flash, etc. Or Actions can inherit a couple even higher level Form and Application controller classes to get state machine functionality on top of the Action Controller. We try to apply that layered style everywhere. And we have been thinking about adding RAD layers -- but have not had the time to get to that...koen.h wrote:Yesterday I was thinking about my ideal setup. It would consist of 3 phases: library->framework->application. Taking the ZF as an example; the zf library would consist of all components you now see in the framework, only there's absolutely no reference to another components class (how I define 100% decoupling). The second phase consists of creating a framework out of that: a structured unit that allows for rapid application development. The third phase are the actuall applications.
Most frameworks skip phase 1. They continue adding functionality to the framework and after a while it get's a mess.
(#10850)
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Re: ZF view coupling
They weren't forced to go outside. There was a perfectly reasonable solution implemented in my Zend_View Enhanced proposal which took less than 50 lines of code but too many people were of the opinion that the Controller should contain that particular function. The reason why Zend_Layout exists is to make View composition using multiple Controllers easier - an approach which underpins that component's entire existence and why it needed Layouts based there, and not Zend_View. If anything it underlines how much attached PHP developers are to historical practice. Still, external or not, it will do the job with a minimum of initialisation code.arborint wrote:That said, I don't know if the ZF View class is that good either. Given the fact that they had to go outside to implement layouts indicates that it may not be the best design.
My own long standing position is that using multiple Controllers to aggregate a View is the most inefficient method imaginable - dispatching a Controller is resource intensive. Doing it more than twice is, in my opinion, a code smell that you are not extracting enough Controller hosted code into separate reusable elements (i.e. an application class library, Models, Helpers, etc.). As with above, it's a common thread in any debate around Controllers and Views.
Indeed, that explains a lot of the use cases for Zend_Layout - elements of the View and Model are left stuck inside Controllers by developers, and never refactored out. Once you go down that route you are accepting that Fat Controllers are acceptable. Fat Controllers have the exact same symptoms as any over long method - it's a known code smell in refactoring and it often encourages code duplication.