-- Christopher Thompson <[EMAIL PROTECTED]> wrote
(on Thursday, 28 June 2007, 12:17 PM -0700):
> I agree with Matthew that identifying the actual use cases that people
> are requesting and then showing the code that solves those use cases in
> the proposed systems is necessary.
The issue is that there are currently two distinct approaches to the
issue of how to include layout support, both of which are valid. The
question, to me, is which makes more sense in the context of the
existing components and leverages existing functionality best.
Also, as you note, there are slightly different use cases, and I think
the "what" of each use case needs to be better detailed, as often
detailing what the desired outcome is will better inform the "how" of
implementation.
> I have had discussions with Pádraic on this subject and looked at his
> and Ralph's code. While I think we agree on the goals, I think they are
> trying to solve specific problems rather than providing support in the
> Zend_View for solving problems. That is a big difference and has been
> the problem to date. Things like viewRenderer() are solutions to only a
> narrow set of problems
Indeed, the goals of the ViewRenderer were clearly laid out in the
proposal and the documentation. From the ViewRenderering documentation,
the goals were:
* Eliminate the need to instantiate view objects within controllers;
view objects will be automatically registered with the controller.
* Automatically set view script, helper, and filter paths based on the
current module, and automatically associate the current module name
as a class prefix for helper and filter classes.
* Create a globally available view object for all dispatched
controllers and actions.
* Allow the developer to set default view rendering options for all
controllers.
* Add the ability to automatically render a view script with no
intervention.
* Allow the developer to create her own specifications for the view
base path and for view script paths.
> and they do not make Zend_View more flexible -- only more confusing.
The ViewRenderer is not an extension to Zend_View. It is a way of
providing convention over configuration to the MVC layer -- follow a
particular set of rules, and things will be done behind the scenes in a
predictable way. It uses the existing functionality of Zend_View, and
simply defines some rules for how to name your view scripts so that the
controller can auto-render them.
I'd love to hear what you find "more confusing" so I can either clarify
things in the documentation or update the code to make things more
clear.
> You can keep tacking things on until you get coverage, or you can go
> back and reimplement the internals to support BC first and then the
> other requested schemes. And it is important to note that the solution
> here is not just in Zend_View, but necessarily in the Action and
> Http_Response as well as they are all a related system.
I don't think there's much change needed in the internals. But you're
absolutely right -- there are a variety of components that need to be
touched or extended to make this work. I like the idea of using View
and/or Action helpers and controller plugins, as these leverage existing
functionality and keep all code fully BC. Loose coupling, and all.
We'll revisit the issue post-1.0.
> Matthew Ratzloff wrote:
> >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>
> >>
> >>
> >
> >
> >
>
--
Matthew Weier O'Phinney
PHP Developer | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
