Matthew Weier O'Phinney wrote:
-- Christopher Thompson <[EMAIL PROTECTED]> wrote
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 don't think there are just two, but more like 4-5. However, I think
that they are all a subsets of a more general scheme that they could be
implemented on top of.
Indeed, the goals of the ViewRenderer were clearly laid out in the
proposal and the documentation. From the ViewRenderering documentation,
the goals were:
I don't question the need for a non-MVC shortcut to render pages, but I
think internally is was don't as a tacked on feature rather than
building on a generic core.
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.
I understand it, but I have poured over the code and written frameworks,
so I am not the target audience. Every time I hear the explanations of
how this stuff works on the lists I have to shake my head. There are
lots of settings; dispatchLoopShutdown() gets bandied about as if it is
a normal/obvious solution; different schemes are needed to achieve
similar things; Controller and View responsibilities are scattered
about. Rendering has evolved from the original not-very-clear system to
a fairly obscure one -- and it still does not really support
hierarchical Views which is the gold standard.
We'll revisit the issue post-1.0.
I think define the use cases, from implicit rendering, through
simple/single View, to Two-Step, to hierarchical, and see what solution
solves them all in the simplest, cleanest, most flexible fashion.
