-- Shekar C Reddy <[EMAIL PROTECTED]> wrote
(on Monday, 25 June 2007, 11:04 PM -0400):
> Just wanted to chime in regarding some naming conventions used in the recent
> MVC enhancements. The following don't appear consistent?
>
> $this->_helper->viewRenderer->setNoRender();
> $this->getHelper('LayoutManager')->useLayoutName(false);
>
> Here are a few more: noViewRenderer, disableOutputBuffering
>
> The more natural way to name a variable, element, method is to use a regular
> name instead of negative phrasing which is more confusing than is convenient:
>
> setNoRender() => setRender()
> noViewRenderer => ViewRenderer
> disableOutputBuffering => OutputBuffering
>
> There are more places where such negative phrasing is manifest in the
> framework
> that appear inconsistent when put to work in tandem with other components as
> noted above. Not too late to rename them for consistency.
I chose the negative naming because these are items that are on by
default; you are choosing to turn them off. While I myself don't
typically like negative names, on the other hand, in this case, I felt
it would force the developer to really think about what they're doing:
"I do *not* want to auto render," "I do *not* want output buffering on,"
"I do *not* want to use the view renderer."
(and don't forget, 'noErrorHandler' :-) )
Basically, in the code, I test to see if the parameter is *defined*; if
not, I proceed as normal, but if it *is*, I do something differently. If
we change to positive names, I actually have to do more work: I have to
set the parameters to default values both in the front controller's
constructor, and also maintain a list of defaults for use with its
resetInstance() method. The negative naming in this case led to simpler
code and maintenance -- a reasonable tradeoff in my mind.
I see the difference in naming in the layout manager as reasonable,
because it will not be on by default (at least not yet). There's also a
key difference: setNoRender() is used to turn off rendering by the view
renderer; that is its sole purpose. Other methods are used to indicate
*which* view to render. Zend_Layout::useLayoutName() differs from this
as it serves both to indicate which layout to use as well as to turn off
the feature. As Zend_Layout is only in the proposal stage at this time,
the API may change to add methods that clearly delineate the two
responsibilities.
Please remember that Ralph's Zend_Layout has not yet been accepted; the
API may change before it is part of the official project (if we accept
it; please also recall that there are some competing proposals for the
layout space currently).
> On 6/25/07, Kevin McArthur <[EMAIL PROTECTED] > wrote:
>
> I think the biggest point is layout just works now and is totally
> backwards
> compatible. It also adds almost no complexity to the app, is entirely
> optional and it's ready for production.
>
> The docs are pretty simple. Here's the 90% usage, but theres more complex
> things like partials not doc'd here
>
> --bootstrap--
>
> Zend_Layout::setup(array('path' => $appRoot. '/application/views/'. $lang
> .'/layouts/'));
> Zend_Layout::setDefaultLayoutName('index');
>
> ---
>
> class DemoController extends Zend_Controller_Action {
>
> public function indexAction() {
> //uses the default layout
> }
>
> public function noLayoutAction() {
> //uses no layout, no view renderer
> $this->_helper->viewRenderer->setNoRender();
> $this->getHelper('LayoutManager')->useLayoutName(false);
>
> fpassthru('/path/to/file');
> }
>
> public function differentAction() {
> //uses an alternative layout
> $this->getHelper('LayoutManager')->setLayoutFile('alternative.phtml');
> }
>
> }
>
> class TextController extends Zend_Controller_Action {
>
> public function init() {
> //Disables the view renderer and layouts for the whole controller.
> $this->_helper->viewRenderer->setNoRender();
> $this->getHelper('LayoutManager')->useLayoutName(false);
> }
>
> public function indexAction() {
> echo "some text";
> }
> }
>
> useLayoutName can also take null to reset to default.
>
> K
> ----- Original Message -----
> From: "Ralph Schindler" <[EMAIL PROTECTED]>
> To: "P draic Brady" < [EMAIL PROTECTED]>
> Cc: "Martin Carpentier" < [EMAIL PROTECTED]>; "Zend Framework
> General" < [email protected] >
> Sent: Monday, June 25, 2007 7:56 PM
> 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
> >
>
>
>
--
Matthew Weier O'Phinney
PHP Developer | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
