It's one of those ongoing debates ;). Those who avoid ActionStack (disclaimer: 
I rarely use them) believe that reusing Controllers in order to construct a 
View is symtomatic of a poorly designed Controller system. Controllers are 
nothing more than supervisors - the Models and View should do all the heavy 
lifting as much as possible (references to Thin Controllers/Fat Models are 
commonplace in Rails land where the concept got its catchy name). Once 
Controllers take on too much responsibility, people hit the problem that unit 
testing Controllers is hard, requires the use of Dependency Injection, and 
usually ends up testing the View (since the Controller has no actual output 
itself except through a View or Model writes). While Rails publicised this a 
lot, it really started back with J2EE where the View Helper design pattern (a 
different concept to what ZF calls a View Helper) was defined in the 
literature. What all of this means in practice - is that
 Controllers are expensive. A View Helper is one simple reusable class, a 
Controller is a class that depends on dozens of other classes doing routing, 
dispatching, action plugin usage, etc, that is far more expensive. You can test 
a View Helper in isolation - you can't with a Controller.

>But what I can gather from the articles is that if I want to display a left
>hand menu, which perhaps lists 'posts' based on a date from the URL, then I
>should write a ViewHelper.  Lets call it My_View_Helper_LeftNav();

Pretty much - the navigation column is then reusable across any View embedded 
in a layout.

>The articles suggest that its fine to allow read access to models from the
>View via the ViewHelper.  So basically all I need to do is grab the date
>from the URL and send it to the Model via the ViewHelper.  I can then spit
>out the results.

It's been a common misconception in the past that Controllers must read Models 
and pass information to Views. This neglects that the Controller is actually 
just reading from a Model, and then passing a second Model (array/object of 
read data) to the Views. The middleman is not always required - just let Views 
read Models directly. The main warning here is that Views must never write to 
Models.

>And thats the problem... how do I access the date from the URL? How do I get
>the request object? Would you get it via the front controllers like this?

This works because the Front Controller in ZF is a singleton. I wouldn't rely 
on that behaviour because it's essentially writing something that depends on 
the existence of a global. The behaviour may (should in my opinion) change with 
ZF 2.0. I would take a slightly more distanced route - add the FC to the 
default Registry and use the Registry in your helpers. I would also encapsulate 
a core response access class as a View Helper - make sure that if FC changes it 
singleton nature, you only need to change one class - not dozens.

>With the Layout/ViewHelper approach is the setResponseSegment pretty much
>redundant?

I wouldn't say it's redundant. Zend_View has evolved to offer flexible 
approaches to composing Views. Segmented responses still serve a purpose, it's 
cheap to maintain, and there's no reason to view it as redundant.

Paddy

 Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative





________________________________
From: Sam Davey <[email protected]>
To: [email protected]
Sent: Tuesday, July 14, 2009 7:29:43 AM
Subject: [fw-general] Actionstack bad, Layout and View Helpers good??


Hi,

I've been reading a number of articles about why the Action Stack is bad and
everything you need to achieve with the action stack could be achieved with
ViewHelpers.

I completely buy into this... I can't remember the number of times I've had
to fudge code because my predispatch hooks are being caled over and over
depending on how many things are in the action stack.  I wish i'd read these
articles 12 months ago.

So I just have a couple of questions about ViewHelpers, Lahyout and URL
parameters.

Zend_Layout is great, full control over layout of the whole application. 
Just spit out your main content via <?php echo $this->layout()->content; ?>

But what I can gather from the articles is that if I want to display a left
hand menu, which perhaps lists 'posts' based on a date from the URL, then I
should write a ViewHelper.  Lets call it My_View_Helper_LeftNav();

Its in the left hand of my Layout so in the layout I'm just spitting it out 
in my layout script e.g. <?php echo $this->LeftNav(); ?>

The articles suggest that its fine to allow read access to models from the
View via the ViewHelper.  So basically all I need to do is grab the date
from the URL and send it to the Model via the ViewHelper.  I can then spit
out the results.

And thats the problem... how do I access the date from the URL? How do I get
the request object? Would you get it via the front controllers like this?

Class My_View_Helper_LeftNav()
{
    public function LeftNav()
    {
        $front = Zend_Controller_Front::getInstance();
        $request = $front->getRequest();
        $date = $request->getParam('date');
}

What would be the recommended method to access URL parameters directly via a
ViewHelper?

Remember I can't communicate it via the Controller because the Controller
is only dealing with the main content and I'm trying to achieve Fat
model/Thin Controller approach and doing away with the action stack.

In the past I've used the action stack, inserted code into the layout using
a <?php echo $this->layout()->leftNav; ?> placeholder and then set the
response segment in the action via <?php
$this->_helper->viewRenderer->setResponseSegment(leftNav); ?>

With the Layout/ViewHelper approach is the setResponseSegment pretty much
redundant?

Cheers,

Sam

P.S. here is one of the articles I was reading:
http://www.rmauger.co.uk/2009/03/why-the-zend-framework-actionstack-is-evil/
-- 
View this message in context: 
http://www.nabble.com/Actionstack-bad%2C-Layout-and-View-Helpers-good---tp24474375p24474375.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Reply via email to