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.
Thoughts?
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
>
