-- Shawn McAllister <[EMAIL PROTECTED]> wrote
(on Thursday, 31 May 2007, 10:55 AM -0400):
> 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...
The ViewRender may be turned off, customized, or even subclassed. The
flexibility is still there; it's just that we've clarified what the
default use scenario we wish to encourage will be.
> 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...
I debated with myself, Ralph Schindler, and the Zend devteam about
whether or not to include it by default. Our consensus was that (a) the
functionality and convenience the ViewRenderer provides fitted the goals
of the framework well (covers the practices we wish to encourage, focus
on simplicity for the developer, and flexibility for the advanced use
cases), (b) there's a path for extending or disabling it in place,
making upgrading relatively easy, and (c) not including it for the 1.0.0
release would mean it could likely never be enabled by default, meaning
that the bootstrap then becomes more complex for the default use case.
So, we introduced a minor BC change. Yes, minor; all you need to do to
disable the ViewRenderer is to add this to your bootstrap:
// where $front is a front controller instance:
$front->setParam('noViewRenderer', true);
> 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.
You don't need to completely rewrite your application to use the
ViewRenderer; if the approach you use in your applications does not fit
the functionality of the ViewRenderer, or if you cannot adequately
customize it to fit your own view layout, there are options to disable
it (as noted above). Please read the migration section for comprehensive
on steps you may take:
http://framework.zend.com/manual/en/zend.controller.migration.html#zend.controller.migration.fromzeroninethree
That said, releases made after this point will be fully BC with previous
releases. That's the main goal of the 1.0.0 release -- to provide a
final API for the core components.
> -----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/
> >
> >
>
--
Matthew Weier O'Phinney
PHP Developer | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
