Hi Ralph, ----- Original Message ---- From: Ralph Schindler <[EMAIL PROTECTED]> To: Pádraic Brady <[EMAIL PROTECTED]> Cc: Zend Framework General <[email protected]> Sent: Tuesday, June 26, 2007 5:30:32 PM Subject: Re: [fw-general] Two-Step View, subclassing controller, etc
>Oh yeah! This is turning into a Bobby Flay style - Zend "What do we do >with layouts" Throwdown! All we need is a bikini clad placard carrier showing which round we're on ;) >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. Sounds like it would allow some for some comparison, so fire away >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? I'll see if that's possible. I have an ultra simple application which may wing it as an example with a little upgrading for my code. I think use cases of a similar nature might be better if they take less time. Regards, Paddy -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> ___________________________________________________________________________________ You snooze, you lose. Get messages ASAP with AutoCheck in the all-new Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_html.html
