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 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 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 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 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 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... The alternate approach be comin' :). Paddy Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com ----- Original Message ---- From: Martin Carpentier <[EMAIL PROTECTED]> To: Ralph Schindler <[EMAIL PROTECTED]> Cc: [email protected] Sent: Monday, June 25, 2007 6:40:23 PM Subject: Re: [fw-general] Two-Step View, subclassing controller, etc Hi Ralph, It looks like a very interesting approach to solve that problem. Is it on the wiki yet cause I can't seem to find it. Also, I was wondering if it was the same kind of solution as the one proposed by Pádraic Brady or if it was a different solution to the same problem ? Thanks, Martin On 6/21/07, Ralph Schindler <[EMAIL PROTECTED]> wrote: > I have a component proposal (writing it as we speak) for Zend_Layout. A > full working implementation can be found at > > http://svn.ralphschindler.com/repo/Xend/ > > (executed in the Xend_Layout namespace) minimal docs and usage is in the > docs folder.. Several people on #zftalk have had a chance to implement > this solution with great ease. > > I will post back when the proposal is updated on the wiki. > > More to come, > -ralph > > Extract from pending proposal: > > Zend_Layout attempts to solve a problem that, since rearing its ugly > head over and over, has gone by many names: Composite Views, Layouts, > Templates, Partial Views, and/or Complex Views. They all basically > attempt to describe a common problem - that of being able to maintain a > consistent look and feel throughout a site or web application while > maintaining the "Don't Repeat Yourself" principals. > > Zend_Layout addresses the problem with a common pattern, the > two-step-view pattern > ( http://www.martinfowler.com/eaaCatalog/twoStepView.html). The Two Step > View pattern breaks the process up into two distinct stages. The > primary stage allows the user requested action as well as layout > requested actions to dispatch and execute their respective views saving > them to the controllers response object. The second stage of the > process takes the already dispatched actions responses and directs them > to the layout where final placement of content is made (in a Layout > specific view) before being sent back to the user. > > Zend_Layout requires no changes to the existing codebase to accomplish > its job. To maintain controller over the dispatch process, Zend_Layout > attaches a controller plugin - this is the essense of the Two-Step-View > and common way to implement the 2SV as we have seen already. > Zend_Layout also registers its own action helper (named LayoutManager), > so that the developer can directly interact with Zend_Layout from within > their actions. > > David Mintz wrote: > > > > This newbie is liking the Two Step View where your plugin basically > > intercepts the response body and sticks it into a sitewide template at > > dispatchLoopShutdown() time. > > > > So: if you want all your controllers to use a common Zend_View object > > (so that the view vars they set will end up available to the sitewide, > > enclosing template), what approach would you recommend? In the name of > > DRY it seems you would might have your bootstrap put the new Zend_View() > > in the registry, and > > > > class MyAppController extends Zend_Controller_Action > > > > { > > public function init() { > > > > $this->view = Zend_Registry::get('view'); > > } > > } > > > > and then have your controllers extend MyAppController instead of > > Zend_Controller_Action. Thoughts? > > > > -- > > David Mintz > > http://davidmintz.org/ > > > > "Our universe is just one of those things that happens from time to time." > > -- Martin Carpentier ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting
