Put simply - every Action is dispatched. Dispatching is one of the frameworks most expensive operations so it is a massive performance sink when used multiple times in every request on a busy site. In comparison, View Helpers do not require dispatching and are therefore far more performant. This isn't some special ZF case either - the same is true for every framework in every language I have ever worked with. You can find it mentioned for Symfony (they mitigate with lighter weight controller types to an extent), Ruby (where the functionality is largely ignored) and Python Django. It's a universal flaw in traditional thinking.
Once again, for Jurian's benefit, this is explained along with the action stack's other fallacies countless times on the web.
View Helpers != Placeholders. A View Helper has no positional data attached - it exists loose until a layout renders it somewhere. And yes, the rendering position is manageable from a configured system. A View Helper can also be as complex as any traditional "fat" controller. They can also be aggregated via composition. In fact, a View Helper is just a normal class with one or more render methods. I never understood the failure to see this or why there's an insistence than it has some major disadvantage - an Action is bound to a controller with dependencies, a View Helper is a free agent without ties.
The only true problem with using them is when your Controllers are magically granted the role of replacing a real Model. I can't help you with that - it's a common mistake but it is not a flaw with using View Helpers.
Paddy
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative
From: Jurian Sluiman <subscribe@juriansluiman.nl>
To: fw-general@lists.zend.com
Cc: Christian Ehmig <ehmig@boerse-go.de>; fw-mvc@lists.zend.com
Sent: Fri, December 4, 2009 1:45:03 PM
Subject: Re: [fw-mvc] PageController + ActionStack vs. Simple MVC
I have almost the same usage. I create "pages" in XML which are decoupled from
the modules. I.e. a contact page uses the module "text" to render some text
and the module "contact" for the contact form. A page "Threecolumns" is just
as simple as three times the module "text" being called. But there are pages
("blog") which just contains the blog module.
I have posted about this issue some time ago, but nobody is able to justify
why you shouldn't use the action helper / stack in this context. Of course you
shouldn't use the stack for breadcrumbs or other *very simple* placeholders
(like your shopping cart inside a storefront module).
But these "blocks" where Christian (I think) and I am talking about are much
more than some simple placeholders. So I don't seem how you're able to use
view helpers with very complex situations.
Regards, Jurian
--
Jurian Sluiman
CTO Soflomo V.O.F.
http://soflomo.com
On Friday 04 Dec 2009 14:15:31 Christian Ehmig wrote:
> weierophinney wrote:
> > -- Christian Ehmig <ehmig@boerse-go.de> wrote
> >
> > (on Friday, 04 December 2009, 02:39 AM -0800):
> >> I've read some discussions about the "evil" ActionStack in this forum
> >> and specifically here:
> >> http://www.rmauger.co.uk/2009/03/why-the-zend-framework-actionstack-is-e
> >>vil/
> >>
> >> I commented on that (#19).
> >>
> >> Now my question is - how do you setup Zend MVC for complex, highly
> >> configurable websites or portals (not only simple blog applications with
> >> basic CRUD operations). In particular, websites that consist of many
> >> conrete
> >> pages that make use of (hopefully) reusable components.
> >>
> >> For me the best solution is still:
> >>
> >> 1. Writing a Zend_Controller_Plugin that hooks into routeShutdown()
> >> 2. in routeShutdown() compile the set of actions, their parameters,
> >> templates and layout targets from a given page configuration (xml file,
> >> database) and the layout file to be used for that page
> >> 3. Push these actions to the ActionStack
> >> 4. done
> >>
> >> Any other approaches seem not reusable and "hard-coded" for me. I can
> >> give
> >> further details on my implementation if needed. I am just curious how
> >> others
> >> solve the issue "a page consists of several actions and their respective
> >> views".
> >
> > I've spoken and blogged a ton on this in the last year. The answer: this
> > stuff is typically either part of your domain model or part of your view
> > layer, but has nothing to do with your controllers.
> >
> > If the reason you're using ActionStack is to re-use business logic...
> > then that logic should be pushed into your models. If the reason you're
> > using ActionStack is to re-use view scripts, then simply consume those
> > view scripts. A judicious use of view placeholders and view helpers can
> > achieve some tremendous results.
>
> I tried to find some posts / blogs about this subject - I would be happy if
> you could provide me with some links to your posts.
>
> About ActionStack - we are using it to re-use both business logic and view
> scripts. If working with only one action per request where is the point in
> having more than one action anyway? I am talking about sth like a
> "PageController" architecture. A request is handled by a PageController
> which knows (from configuration) how to render the page. This includes the
> layout, the actions + their parameters and templates. If you try to
> implement re-usable actions, a single page will always consist of several
> action calls.
>
> Simple example:
>
> listArticlesAction() which lists a set of articles using a given template -
> the action itself queries it's data from the model: $model->getArticles()
> by passing parameters.
>
> Now, you like to display different sets of articles on different pages and
> it should be completely configurable - much like in a typical CMS with db
> backend.
>
> I cannot see any benefit from using view helpers or placeholders here
> instead of an ActionStack. Where would you effectively configure which set
> of articles to display on a given page. Also think of several different
> sets of articles per page. This sould easily be re-configurable in any
> point of time.
>
> When using the ActionStack, you have complete control by building the stack
> via a given configuration.
> Please correct me if I'm wrong and sorry for coming up with this topic
> again...
>
Once again, for Jurian's benefit, this is explained along with the action stack's other fallacies countless times on the web.
View Helpers != Placeholders. A View Helper has no positional data attached - it exists loose until a layout renders it somewhere. And yes, the rendering position is manageable from a configured system. A View Helper can also be as complex as any traditional "fat" controller. They can also be aggregated via composition. In fact, a View Helper is just a normal class with one or more render methods. I never understood the failure to see this or why there's an insistence than it has some major disadvantage - an Action is bound to a controller with dependencies, a View Helper is a free agent without ties.
The only true problem with using them is when your Controllers are magically granted the role of replacing a real Model. I can't help you with that - it's a common mistake but it is not a flaw with using View Helpers.
Paddy
http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative
From: Jurian Sluiman <subscribe@juriansluiman.nl>
To: fw-general@lists.zend.com
Cc: Christian Ehmig <ehmig@boerse-go.de>; fw-mvc@lists.zend.com
Sent: Fri, December 4, 2009 1:45:03 PM
Subject: Re: [fw-mvc] PageController + ActionStack vs. Simple MVC
I have almost the same usage. I create "pages" in XML which are decoupled from
the modules. I.e. a contact page uses the module "text" to render some text
and the module "contact" for the contact form. A page "Threecolumns" is just
as simple as three times the module "text" being called. But there are pages
("blog") which just contains the blog module.
I have posted about this issue some time ago, but nobody is able to justify
why you shouldn't use the action helper / stack in this context. Of course you
shouldn't use the stack for breadcrumbs or other *very simple* placeholders
(like your shopping cart inside a storefront module).
But these "blocks" where Christian (I think) and I am talking about are much
more than some simple placeholders. So I don't seem how you're able to use
view helpers with very complex situations.
Regards, Jurian
--
Jurian Sluiman
CTO Soflomo V.O.F.
http://soflomo.com
On Friday 04 Dec 2009 14:15:31 Christian Ehmig wrote:
> weierophinney wrote:
> > -- Christian Ehmig <ehmig@boerse-go.de> wrote
> >
> > (on Friday, 04 December 2009, 02:39 AM -0800):
> >> I've read some discussions about the "evil" ActionStack in this forum
> >> and specifically here:
> >> http://www.rmauger.co.uk/2009/03/why-the-zend-framework-actionstack-is-e
> >>vil/
> >>
> >> I commented on that (#19).
> >>
> >> Now my question is - how do you setup Zend MVC for complex, highly
> >> configurable websites or portals (not only simple blog applications with
> >> basic CRUD operations). In particular, websites that consist of many
> >> conrete
> >> pages that make use of (hopefully) reusable components.
> >>
> >> For me the best solution is still:
> >>
> >> 1. Writing a Zend_Controller_Plugin that hooks into routeShutdown()
> >> 2. in routeShutdown() compile the set of actions, their parameters,
> >> templates and layout targets from a given page configuration (xml file,
> >> database) and the layout file to be used for that page
> >> 3. Push these actions to the ActionStack
> >> 4. done
> >>
> >> Any other approaches seem not reusable and "hard-coded" for me. I can
> >> give
> >> further details on my implementation if needed. I am just curious how
> >> others
> >> solve the issue "a page consists of several actions and their respective
> >> views".
> >
> > I've spoken and blogged a ton on this in the last year. The answer: this
> > stuff is typically either part of your domain model or part of your view
> > layer, but has nothing to do with your controllers.
> >
> > If the reason you're using ActionStack is to re-use business logic...
> > then that logic should be pushed into your models. If the reason you're
> > using ActionStack is to re-use view scripts, then simply consume those
> > view scripts. A judicious use of view placeholders and view helpers can
> > achieve some tremendous results.
>
> I tried to find some posts / blogs about this subject - I would be happy if
> you could provide me with some links to your posts.
>
> About ActionStack - we are using it to re-use both business logic and view
> scripts. If working with only one action per request where is the point in
> having more than one action anyway? I am talking about sth like a
> "PageController" architecture. A request is handled by a PageController
> which knows (from configuration) how to render the page. This includes the
> layout, the actions + their parameters and templates. If you try to
> implement re-usable actions, a single page will always consist of several
> action calls.
>
> Simple example:
>
> listArticlesAction() which lists a set of articles using a given template -
> the action itself queries it's data from the model: $model->getArticles()
> by passing parameters.
>
> Now, you like to display different sets of articles on different pages and
> it should be completely configurable - much like in a typical CMS with db
> backend.
>
> I cannot see any benefit from using view helpers or placeholders here
> instead of an ActionStack. Where would you effectively configure which set
> of articles to display on a given page. Also think of several different
> sets of articles per page. This sould easily be re-configurable in any
> point of time.
>
> When using the ActionStack, you have complete control by building the stack
> via a given configuration.
> Please correct me if I'm wrong and sorry for coming up with this topic
> again...
>
没有评论:
发表评论