In my opinion... The changes that have been made are idiotic to say the least... The main motivation for using ZF was that it allowed for a lot of flexibility... Now you have introduced the very thing I hate about frameworks in general... Strict adherence to your view of development methods and structure... Honestly, I am quite pissed that I now have to go back and rewrite a lot of what I have written... I was quite convinced that 1.0 would present itself as backward compatible... But this new ViewRenderer bullshit just wasted a lot of my time if I choose to upgrade... Which I must. I almost feel like I should have gone with symfony now... Because the reasons I had for not using it are now rearing their ugly heads in 1.0RC1.
-Shawn -----Original Message----- From: Justin Plock [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 30, 2007 4:49 PM To: Kevin McArthur Cc: Matthew Weier O'Phinney; [email protected] Subject: Re: [fw-general] ViewRenderer Problems I agree with Kevin. I prefer to keep all of my HTML open and close tags in one file and include self-contained sub-sections as necessary. I've begun using most of the other Zend-classes but this piece of MVC is a major stumbling block for me on adoption. Thanks. -Justin On 5/30/07, Kevin McArthur <[EMAIL PROTECTED]> wrote: > List debate time =P > > > The issue with this approach is that it becomes very difficult to > > visualize the end product -- and then, from the end product, to > > determine where a particular piece of HTML came from. Consider how > > difficult it can be to find a particular nested tag when traversing > > the DOM, for instance -- a container view is much more difficult to > > visualize for most people > > I'd think it'd be harder to figgure out the end product if its all in > different templates and is being included from views controllers, > plugins and helpers. > > The container approach is the same as OOP really, offering > encapsulation. It also follows HTML, which is in-itself a container based appraoch (ie DOM). > > Consider the following templates > > layout.php > > --- > > <html> > <head> > <?= $scripts ?> > <?= $styles ?> > </head> > <body> > <?= $body ?> > </body> > </html> > > This is really easy to find a mismatched tag, and chase down unclosed > elements. Sub elements can be sub-templates and so on... its all very > separated. Thinking of this process linearly, is imho a lot more > complicated as you have to match up a number of files that are not > hierarchically distributed. > > I'm not sure why, in such a highly oop framework, the inclination > would be to go to procedural style views? > > > I try to limit exactly what templates a non-developer can work with, > > and in most cases, they should not have to do any logic; they simply > > indicate whether or not it should be included in the page, and what > > content should be passed into it. I also segregate templates into > > application templates (i.e., the general container for the > > application content), item templates (what individual items can be > > included into the application template), and finally the actual > > page-level template (which includes the header, footer, and sitewide navigation elements). > > Typically, any given content editor will only need to deal with the > > *content* for the application level, which might include choosing > > which items to utilize. It's a container approach, but differs from > > the one you propose as most of the actual work is done at the view > > level instead of within the controller. > > Templates should be easy to change and skin without bugging technical staff. > This is a pretty common workflow. It's mostly for that workflow reason > that I favor dumb templates with controllers doing all the work, > especially when touching the model which might affect database state > etc and make debugging a real super pain. Why would you want to have > to trace templates (which were presumably coded by someone else) in > order to follow the applications logic instead of simply tracing the > controler/action chain. It's a question of centralized, clearly defined, demarcation of responsibility. > > > However, I'm not going to try and convert you -- if the container > > paradigm works for you, then that's good, too. > > The question is how to make both paradigms easy to use for maximum adoption. > > > I think for the bulk of > > those using ZF, however, the methods outlined for using the > > ViewRenderer and Two-Step View are going to work well, and something > > will be built on top of these for layout support. For those like > > yourself and Kevin, there will be alternate systems developed, but > > as to whether or not they will be included directly in ZF is another question. > > Two-Step view is too complicated right now. It requires understanding > the dispatch process intimately, and authoring plugins (something i'd > consider advanced, un-everyday use) > > This approach needs to be simplified with some sort of > addMasterTemplate() + > useMasterTemplate() or similar calls being added to the viewrenderer. > Standardization on this is critical for easy adoption. I'm working on > a solution, when I come up with something elegant, I'll share. > > Kevin > > >> On May 30, 2007, at 3:20 PM, Matthew Weier O'Phinney wrote: > >> > >> > -- Kevin McArthur <[EMAIL PROTECTED]> wrote (on Wednesday, 30 > >> > May 2007, 12:59 PM -0600): > >> > > Seems like a % of developers think about templates as a series > >> > > of concatenated strings (header.tpl, content.tpl, footer.tpl) > >> > > and others (like you+me) think about them as a series of > >> > > containers. The viewrenderer somewhat presumes the former, but > >> > > with a plugin can do the latter. > >> > > >> > I think of them as containers as well, but I also have each > >> > controller action doing a very discrete task, which means that > >> > any individual action is only rendering one chunk of the page. I > >> > then assemble my final view in a dispatchLoopShutdown() plugin. > >> > The main purpose of the named segment support in the response > >> > object was to facilitate exactly this sort of idea -- aggregate > >> > all your various content pieces, and then assemble them later in > >> > a larger container (or containers). > >> > > >> > Be aware that you can do a lot *within* a view script as well. I > >> > often will pull data directly from models, or render sub-views > >> > from within these views. As a result, I rarely need to do more > >> > with a view object from the controller than assigning variables and rendering. > > > > -- > > Matthew Weier O'Phinney > > PHP Developer | [EMAIL PROTECTED] > > Zend - The PHP Company | http://www.zend.com/ > >
