Page 1 of 2
ZF view coupling
Posted: Fri May 23, 2008 11:29 am
by koen.h
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.
Re: ZF view coupling
Posted: Fri May 23, 2008 12:35 pm
by Christopher
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?
Re: ZF view coupling
Posted: Fri May 23, 2008 1:06 pm
by koen.h
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.
Re: ZF view coupling
Posted: Fri May 23, 2008 2:17 pm
by Christopher
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.
Re: ZF view coupling
Posted: Fri May 23, 2008 3:09 pm
by koen.h
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.
Re: ZF view coupling
Posted: Fri May 23, 2008 3:33 pm
by Christopher
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.
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:-bootstrap sets it in registry or similar object and actioncontroller uses that
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:-actioncontroller instantiates it manually
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:Not every action controller might need a view though.
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:That leaves option 2. Less user friendly, very modular.
I am not sure. It seems like part a naming issue and part and assembly issue. Here are some permutations:
- 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();
Re: ZF view coupling
Posted: Fri May 23, 2008 4:21 pm
by koen.h
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();
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.
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).
Re: ZF view coupling
Posted: Fri May 23, 2008 4:32 pm
by Christopher
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.
I was really just using that as an example that you would get it from somewhere...
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.
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).
Yes, but it would not necessarily restrict if the loader was a convenience method and you could still load the View yourself.
The design issue we are struggling with in Skeleton is assembling Templates/Views in a hierarchy (often called layouts).
Re: ZF view coupling
Posted: Fri May 23, 2008 5:05 pm
by koen.h
arborint wrote: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.
I was really just using that as an example that you would get it from somewhere...
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.
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.
The design issue we are struggling with in Skeleton is assembling Templates/Views in a hierarchy (often called layouts).
What's wrong with the zend layout approach?
Re: ZF view coupling
Posted: Fri May 23, 2008 6:12 pm
by Eran
arborint, you said you need people for your Skeleton framework. Could you elaborate?
Re: ZF view coupling
Posted: Fri May 23, 2008 7:20 pm
by Christopher
pytrin wrote:arborint, you said you need people for your Skeleton framework. Could you elaborate?
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.
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

). We have the start of ActiveRecord, TabledataGateway and DataMapper implementations. Our loose coupling goal and building-blocks style makes the design demanding. For example the goal is not one OR/M solution, but a layered set of solutions.
Re: ZF view coupling
Posted: Fri May 23, 2008 7:57 pm
by Christopher
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.
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:What's wrong with the zend layout 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.
Re: ZF view coupling
Posted: Sat May 24, 2008 7:29 am
by koen.h
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.
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.
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.
Re: ZF view coupling
Posted: Sat May 24, 2008 12:02 pm
by Christopher
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.
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: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.
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...
Re: ZF view coupling
Posted: Mon May 26, 2008 3:03 am
by Maugrim_The_Reaper
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.
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.
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.