Oh yeah! This is turning into a Bobby Flay style - Zend "What do we do
with layouts" Throwdown!
In all seriousness, it would be fruitless to respond to this here. I
think we should move this to the wiki, in a Q&A style, left-right - left
being the ZVE POV and right being the Zend_Layout POV.
This will allow us to track the goals, design notes, and discussions
that are taking place, and in a more structured (less FUD) fashion.
http://framework.zend.com/wiki/display/ZFDEV/Zend_View+Enhancement+VS.+Zend_Layout+Throwdown
I also think we should both develop sites on our proposed solutions so
that we may better demonstrate our points, what do you think of that?
-ralph
Pádraic Brady wrote:
Ralph,
You'll have to forgive me, but I haven't read all your code yet - if I
batter the wrong door let me know :).
>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 is NO rewrite required, Ralph. There are no life-altering changes.
My proposal addresses most of the complex/commonplace/modern day
problems in a few dozen lines of code which is entirely backwards
compatible and decoupled from the current Zend_View. Less FUD, more
substance...
The common modern day application of MVC, and yes to web applications,
is for the View to control layout and presentation. This has always been
at the core of the MVC View (with relatively few exceptions). It's at
the core, because of one simple ideal - the View reads from the Model.
There is absolutely no reason to pass through a Controller all the time
- none, zero, squat. I haven't a seen a single solid reason why this is
perceived as a requirement. Perhaps my PHP days were spent in the
wilderness, but it's alien to my experiences outside PHP.
Your approach is based on using Controllers to render parts of a View.
This again is not necessary - the clearly defined pattern is Composite
View and it nests Views (i.e. scoped partials) not Controllers. At the
end of the day, you're subtly loading the Controller with responsibility
outside it's MVC scope - what is it you see the Controller as being
responsible for??? You're free to so once its decoupled (which it is).
But in doing so you're advocated a complex solution to an incredibly
simple set of problems.
There are a handful of reasons where passing through the Controller can
be useful - it can sometimes be simpler, more convenient and require
less maintenance esp. where an existing Controller is embeddable and it
would defy DRY to duplicate it inside the View. In most cases though
it's a recipe for a maintenance and performance disaster. Try playing
this tune game in J2EE or Ruby and you would be quickly hung, drawn and
quartered by some pedantic Java Bean ;). I've seen controller based
solutions over the years - they are nearly always inefficient (in every
sense of the word). I see no reason to expect better of a PHP based variant.
Finally, you're ignoring KISS. My proposal does not necessitate "major
architectural changes". That's either lunacy, or you were being
sarcastic - I can't tell which. The majority of the changes in Zend_View
Enhanced Proposal relied on adding simple View Helpers. I note you
"borrowed" the same approach after my proposal was released ;). Just as
I "borrowed" it from a dozen other frameworks (although it's pretty
funny how everyone blames it on "borrowing" from Symfony only :)). Just
as they borowed it from who knows what - good ideas always rise to the
top eventually.
>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.
F.U.D. - Fear, Uncertainty and Doubt. Please...
There are no major architectural changes, and there are no backwards
compatibility problems. If want to campaign against Zend_View Enhanced
you'll need better ammunition then FUD. Better still, why not run down a
copy of my code and illustrate these FUDish assertions? Now that would
be cool - if I have made a blasting major architectural change, or
compromised backwards compatibility, then my code is in direct violation
of my Proposal requirements which declare a few soft objectives about
compatibility. If I am in the wrong (always possible!) at least fire me
a "fact".
Controllers are time efficient View partials assuming they are wholly
embeddable, and where doing a View based alternative violates DRY.
Inefficient in terms of performance, but efficient in that by avoiding
DRY you spend less time developing. Your concern I would assume is that
Views might be hijacked into altering the Model via a controller
dispatch. Very valid concern - but there is no method to ringfence the
Model except applying discipline.
I personally dislike dispatching controllers from the View for this very
reason. It is however a View Helper (it doesn't actually need changes to
Zend_View) and easily executed on the spot when the proposal is being
reviewed. It's usefulness is embedding controllers - what other
frameworks might refer to as "components" (for example, Rails). Hard to
ignore that advantage from the POV of a template driven View.
Resource intensive scripts would arrive with any Controller based
solution. It inherently requires more objects, more processing, etc.
What do your Zend_Layout nested units live on? Your Pot is at least as
Black as this one ;).
>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.
You are assuming a page needs multiple controllers - which is untrue.
Such a requirement is a personal preference which does not reflect
common practice in MVC - which is that the View does most fiddly stuff
like this. Also it's *not* Two-Step View - if you want to be pedantic
there's the tiniest hint of it at best. Two-Step View is defined in
POEAA - Matthew's plugin solution while not entirely Two-Step is close
enough that the term works. What Zend_Layout does is way off course from
the Pattern. Not sure what pattern applies here...
>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.
It's not a light solution. I've seen the amount of code you need to pull
this off... It dwarfs my own code by a wide margin.
>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.
That is a ton - relative to the alternative. I haven't seen any similar
solutions (or heard from the authors) that I know of. I know plenty of
folk on my approach. Likely we're just moving in different groups of
diverging rebels :). Vive la resistance, mon ami!
>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.
How is it inflexible? How is it not a complete solution? I can't ward
off this attack without fodder to chew on. I can't even tell if you
meant it to be FUDish! :)
I bet ZVE covers well over 80% of the typical Layout needs as is (I'd
assume more, but everyone has an edge case they insist on using and it's
not like I polled the community). I also bet you haven't checked how
deep Layouts can be nested using Partials which with Module crossing
behaviour actually implement the Composite View Pattern - not simply a
reusable snippet renderer. My flexibility is getting very close to
meeting everything I've ever needed. I'll wait for a use case to prove
otherwise.
Web-MVC as applied in J2EE is capable of everything I've mentioned.
Personally I think too much crap is laid at the door of Web-MVC, or
similar excuses. I've interpreted MVC the same way I learned it when
starting with Java - by reading "POEAA" and "J2EE Design Patterns". I'm
sure both have extracts about this stuff across half the internet...
There is nothing in my approach which hits the Web-MVC barrier.
Best regards,
Pádraic
Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com
----- Original Message ----
From: Ralph Schindler <[EMAIL PROTECTED]>
To: Pádraic Brady <[EMAIL PROTECTED]>
Cc: Martin Carpentier <[EMAIL PROTECTED]>; Zend Framework
General <[email protected]>
Sent: Tuesday, June 26, 2007 2:56:16 AM
Subject: Re: [fw-general] Two-Step View, subclassing controller, etc
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
------------------------------------------------------------------------
Building a website is a piece of cake.
Yahoo! Small Business gives you all the tools to get online.
<http://us.rd.yahoo.com/evt=48251/*http://smallbusiness.yahoo.com/webhosting/?p=PASSPORTPLUS>
