First and foremost, its important to know that Zend_Layout implements a
well known and well documented pattern which has been discussed here
before, the Two-Step-View.
Pádraic Brady wrote:
Hi Martin,
From reading the proposal extract it seems like a solution to some
similar problems I elaborated on in the Zend_View Enhanced proposal. The
difference is the method of aggregating output. Zend_View Enhanced
places that responsibility in the View (Composite View Pattern, View
Helper Pattern). Ralph's proposal would place in the Controller which is
similar but not the same.
I see alot of value in what you propose as it absolutely represents
simplicity. It does not tackle the more complex, commonplace, or modern
day problems with a clean solution that wouldn't require a re-write of
the current controller or the view... That of being able to invoke
Layout specific action requests.
There are a few problem with Padriac's proposal of the controller
plugin. First, it does not work without a change to the existing view
and controller. This means major architectural changes that would not
be backwards compatible. Second, this plugin introduces a few tenants
to the ZF MVC implementation that I personally am not a fan of: a)
Views with the power and ability to be able to dispatch other action
controllers and b) MVC nesting. This nesting would lead to resource
intensive scripts (having to manage multiple concurrent controllers and
views each with their own state), and would be extremely difficult to
trace debug.
I haven't seen Ralph's implementation beyond the original Layout code he
posted a while back, but my argument against a Zend_Layout at the time
remains the same - the Controller manages workflow and is unsuitable for
managing presentation issues like Layout. The simple reason being that
Quite the contrary. If any given page needs 3 action controllers
dispatched to complete a page, who better to control this flow than the
Controller? The Layout manager gathers information either at runtime or
config time in order to know which actions need to be dispatched in
stage 1 of the two-step-view for assembly in the second stage of the
two-step-view.
The fact that the layout manager processes the actions as a stack
instead of nesting allows for a very light and flexible solution, FAR
FAR from being unsuitable.
the Controller will use and depend on significantly more classes,
require extra controller actions to be written by the user, and
therefore require additional processing - and it all needs a ton of
code. It's akin to using a sledgehammer to stick a thumb tack into
No, not a ton, a Controller plugin (LayoutProcessor - meat and bones of
the Two-step-view), many people have already implemented solutions like
this.. and an Action Helper (This allows for developers to communicate
with the layout system), and an overall class Zend_Layout, to tie it all
together into a configurable system.
something. Other languages have consistently abandoned or advised
careful use of similar constructs in the past. My own Layout
implementation is scarcely a screen full of code - a simple decorator
effect.
I don't disagree, in fact, aspect of bing able to attach a layout to
view would solve the simpler problem, but once people will start digging
for a more complete solution, they might find themselves up against a
wall thats not as 'extremely flexible' at the end of the day.
I think I called this the framework's "Controller obsession" in my
original response...;). Few people in PHP seem to apply the View Helper
pattern (Views using a read only Model API to read from the Model
without Controller dependecies). The pattern is pretty standard outside
PHP. That said, my proposal has a requirement not to prevent Controller
Keep in mind, this isn't the MVC as proposed for smalltalk and the
desktop world, its the Web-MVC, or the Cli-MVC as interpreted by the
Zend Framework. Everyone is entitled to their own interpretation of the
MVC and that is why there are a bigillion frameworks.
The controller is important for dispatching user requested actions from
the device that the user is using and as such is responsible for
delivering the final product back to the user.. this means it should
probably have a hand in the subsystem that assembles the response.
based solutions. I hadn't realised Ralph has started implementing the
same functionality as Partials and such though :). They all require
changes at the View level (partials are a simple rendering mechanic)
which one assumes is out of Zend_Layout's scope...
Again, no changes needed to the core for the Zend_Layout solution. In
fact, if a user decided layouts make no sense in their cli environment,
they can simply not use Zend_Layout.
In summary, Zend_Layout is a standards driven component that is very
fast, flexible and extensible. The only thing that is lacking is a
solid example (which Kevin McArther has) and some documentation.
-ralph
