Ralph, you're one step ahead of me. But instead of broad dissertations on the role of Controllers, Views, and Models, what I'd like to see is concrete end-user code showing how each would work. Not just controllers, but sample views as well. Establish a use case and then show how each solution would solve it.
Since Pádraic has already put up a proposal, what you might do is copy his use cases into your Layout Throwdown '07 wiki page and then translate them to how Zend_Layout works. I also would really, really like to see layout support integrated into Zend Framework as soon as possible. The difference is that if that's a 1.1 release two to four weeks down the road, that's fine. The key is releasing soon after 1.0. -Matt On Tue, June 26, 2007 9:30 am, Ralph Schindler wrote: > 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 <fw-general@lists.zend.com> >> 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> > > >
