Why the Zend Framework Actionstack is Evil


The action stack seems to be a useful component to some people when starting out with the Zend Framework. This component is a seemingly un-needed part of the framework, as there really is no use-case for it which cannot be simplified with the use of a partial view, which reads data directly from the model, possibly with a view helper alongside to provide some additional logic function, such as deciding on which view partial to use.

This part of the Framework causes the dispatch to loop. This is a costly process, as it involves quite alot. It also adds some further issues to your application design, such as where you should put code. for example if you have some code in your predispatch, and your looping through two actions in that controller, that code will be run twice. This is obviously, not good, and quite un-needed. Further complications can be added when it comes time to add ACL or authentication.

There is an even worse part of this feature, the Action View Helper. This helper basically creates an additional dispatch, copying the request object, and creating a loop-within-a-loop . The setting up of the dispatch process is a costly one, anyone who has profiled their code will have seen just how much of the process of a Zend Framework application this eats up. Creating a whole extra dispatch must be a bad idea, even the Zend Framework Performance Guide notes this fact

So, lets go through some reasons for this being bad.

Why its bad

Performance

Every time you go through the dispatch process, there are a number of things which are done, which will be completly un-nessicary for your action, namely calling preDispatch and postDispatch for each action which is called. This often results in questions in #zftalk of “Why is my ACL being called twice?”. If you have an ACL being built in your preDispatch (as many people quite rightly do) this means if you have 3 calls to different actions, your ACL will be built, and queried 3 times, and if you haven’t cached your ACL object, this may incur extra overhead from calls to database queries.

This is even more apparent if you use the action helper, as the request is copied, and a new dispatch created (profile your code and see just how much overhead this involves, its a lot!).

Unnecessary Complexity

Trying to follow the application flow through an application which utilises the action stack adds a level of complexity which need not be there.

If you want to see what’s going on at a URL, you should be able to go to that action, and see which model methods are being invoked, and what is being passed to the view.

Design Issues

This is the biggest reason for not using the action stack. If you are using the action stack, you are almost certainly a long way from a true “MVC” design. The units of code you are using in your actions, probably belongs in the model.

Your model should encapsulate all the code to extract data, insert data, and manipulate objects, so all your controller action should include is a bunch of calls to the model to fetch data, or insert/update it, but in the form of single method calls only. remember you should be directing the data to the model, not manipulating it.

Why it is good

Illusion of DRY coding

The action stack can lead you into a false sense of security that your writing nice “DRY” code. You are in fact writing dry code, but usually in the wrong place, in fact, if your code is not abstracted into your model, it will end up no-longer being dry, as you will end up with two actions with overlapping functionality, and as such, overlapping code!

The way forward

Fat Models, Thin Controllers

Your controllers should be minimalist. they exist only to direct data, and to provide some interface to HTTP actions such as redirects.

The bulk of the code in your application should be in your model. For example, if you are writing a blog application, and the action you are writing produces a list of posts. This should require in the action, nothing more than a call to $model->getPosts(); possibly passing one or more paramaters from the URL (such as year and month) as parameters to the method.

This not only allows you to do away with the action stack, but also allows your code to be portable throughout the application, in true DRY style.

There is an upcomming book, which has a very good overview of how these kinds of models should be written. You can read it here

View Helpers

View helpers can be useful for items which you frequently need, or for items which are simply too small to justify writing a whole view script for them. there is a good example in the performance guide.

When you want to perform some logic before rendering a view script, a view helper can also be useful to help keep your layout or view free of large switches or if statements. For example this can be something like rendering a login form when a user is not logged in (which would require no view script, only a Zend_Form object), and a menu when they are, or be useful to set up some context for a view partial before rendering it, so that your controller does not have to pass a variable to the view when it would be some default value.

(Partial) Views

Partial views do the leg work of replacing the actionstack. In your partial views, you should call read-only methods of the model, to build items such as menus. this could be something like $model->getSideBarMenuItems(); which would return a dataset to loop through and render.

Some other notes

There has been an issue raised in the Zend Framework JIRA (ZF-5840) with regard to removing the action view helper for ZF version 2.0. This is somewhere you may wish to post your opinion on this subject (keep it specific!), or vote to have it removed ;) .

, , , , ,

  1. #1 by Ben Scholzen 'DASPRiD' on March 10, 2009 - 12:34 pm

    Very good article, Ryan. Finally someone has written down our thoughts :)

  2. #2 by Ryan on March 10, 2009 - 12:37 pm

    Thank you. I have been meaning to get this all written down for a while. I will add a little more soon (some code examples and a diagram or two).

  3. #3 by Sudheer on March 10, 2009 - 12:56 pm

    Glad you published it. I have seen some folks using an action to generate the menu. Hopefully, they will implement better menu generation and rendering program.

  4. #4 by Matthew Weier O'Phinney on March 10, 2009 - 2:01 pm

    I’m wishing I’d not succumbed to users who wanted both ActionStack and the action() view helper. Both introduce overhead, and both also lead to difficult to debug code. As you note, there’s almost nothing you can do with either that you could not do with a partial or a view helper — including things such as menu and navigation generation.

  5. #5 by Kieran Hall on March 10, 2009 - 2:40 pm

    Well said. When I started out with ZF I encountered the Actionstack, and a whole load of problems – many of which you touch on. Realising that my requirements could be met using much more MCV-centric components, I abandoned the Actionstack and have never looked back.

    People like me, 12 months ago, should read this article before building their first serious ZF Application.

  6. #6 by Cristian on March 12, 2009 - 1:59 pm

    I am investigating also some ways to avoid using ActionStack for widgetized content to see what effective options we have. I am trying to put some very simple sample cases.

    1. Using view->render

    Into action controller prepare data for those areas and set it to view: $this->view->data = LoadDataFromModel.

    Then on view we are simply making a $this->render(‘widgetA.phtml’), and widgetA.phtml makes use of data supplied to view;

    This is probably the fastest into processing terms, no helper used.

    2. Using view->render with layout & response segments

    Let’s suppose on Layout we have two zones, zone1, and zone2 with witgetized content (data from some diff sources).

    layout()->zone1?>

    layout()->content?>

    layout()->zone2?>

    Into action controller prepare data for those areas and set it to view $this->view->data = $data_from_model.

    Then:
    $response = $this->getResponse();
    $response->insert(‘zone1′, $this->view->render(‘widget1.phtml’));
    $response->insert(‘zone2′, $this->view->render(‘widget2.phtml’));

    Advantage of this methos would be the fact that is adapted to use of layouts.

    3. Using view helpers without layout – fixed widgets

    This is similar as 1, just that:
    - Instead of $this->render(‘widgetA.phtml’) we are calling helper: $this->widgetA(….)
    - Data is loaded by helper, not on action

    I said fixed widgets because in such case the widget call is hardcoded into a specific template, so we won’t really have the option to use diff widgets on same position depending on case

    3. Using view helpers without layout – dynamic widgets

    This is similar with3, just that:

    - Instead of calling $this->widgetA(….) we are calling $this->widget(….)
    - $this->widget(….) dynamically select the proper widget to call and it returns his return result

    5. Using view helpers with layouts

    This is similar as 2, just that on action we have something like that

    $response = $this->getResponse();
    $response->insert(‘zone1′, $this->view->widgetA());
    $response->insert(‘zone2′, $this->view->widgetB());

    And of course, we can automatically select the widget to be called.

    Might be other ways, i just tried to make a list to see choices…

  7. #7 by Cristian on March 12, 2009 - 2:10 pm

    I forgot about partials:

    1b. Using partial

    Into action controller prepare data for those areas and set it to view: $this->view->data = LoadDataFromModel.

    Then on view we are simply making a $this->partial(‘widgetA.phtml’, $this->data)

  8. #8 by julien-pauli on March 13, 2009 - 10:00 am

    Well, I guess it depends the kind of MVC you’ll use.

    Push or pull MVCs differs from the fact that the view can have acces to the model, or must be given it throught a controller.
    ActionStack can be usefull in push MVCs, (keeping your exemple) as the decision to show a form or a logout button will be taken in a controller and not in a view helper.

    But I agree that the strength of the application should be concentrated in the model classes

  9. #9 by DangerMouse on March 17, 2009 - 3:40 pm

    Hi there,

    An interesting post, and I agree with your approach entirely. However, I’m interested in views on the following:

    - Standard MVC dictates that the View should not updated the Model, only read from it. How do you access data that is not spoon fed to the View via the controller? By default if you want data that isn’t associated with the current request – typical of sidebar style content – u have to instantiate the relevant part of the model. Instantiation is effectively writing to the Model from the View.

    How would you reconcile this?

    An example would be a Navigation. A Navigation model relies on the Request, although it is not neccessarily related to the core data that the View requires. Blog post model object gets passed to View for display, I’m not convinced that the blog post object should have methods to get Navigation elements or that the Navigation elements should be instantiated within the controller and passed to the View sperately. This leaves instantiation from a View Helper.

    Thoughts?

  10. #10 by Ryan on March 17, 2009 - 4:02 pm

    Firstly Thank you Everyone for your comments!
    And a huge thank you to Rob Allen for his link on the Zend Framework In Action Homepage.

    DangerMouse: As Matthew Weier O’Phinney mentioned, navigation should be done with a partial or view helper.
    You can render a partial from your controller should you wish, as you have access to the view from there, you can simply render a script to a view variable, such as this: $this->view->nav = $this->view->render(‘my/nav/script.phtml’);

    MVC also does not dictate that at all. infact if you look at the little triangle diagram you usually see with any detailed explanation of MVC, there is an arrow pointing from the model to the view, this is to show that the view should also be able to read from the model.

    Using a view helper for creating such navigation is also useful, as you can set a default value to be the id you use when querying the model for the elements you wish to render, that way you don’t need to assign a value to the view in every action, and only in those where it is required that the navigation shows something different.

    Every case should be taken upon its own merits, but no case really *needs* the action stack, and definitely none should require the action view helper to reach a sensible resolution.

  11. #11 by funnyman on March 24, 2009 - 3:31 am

    Hi Ryan,
    Thanks for this useful post. No doubt, widgetized content is ubiquitous. There are are few points i’d like to raise:

    1. “as there really is no use-case for it which cannot be simplified with the use of a partial view”
    This sounds like probably a mere quick hack to avoid the ActionStack. It does solve the problem, but maybe not ALL the problems.

    The reason why this article is written is simply because the ActionStack costs too much resource. It is not because it is not a good idea. Using ViewHelper to solve this problem is a hack. Ideally, the ViewHelper should only be passive and the “if foo render x, else render y” logic should be done in controller.

    2. Proposed solution
    The idea of ActionStack is *GREAT*. It should live. However, it should be modified to something more light-weight.
    Maybe ZF should have something to handle communication between different modules. I call it an “internal dispatcher” & “internal requests”. The dispatcher works with the stack with full & cumbersome requests. The internal dispatcher works only with interenal requests and apparently those requests should be minimal.

    I don’t know yet know how to create such a mini-request & dispatcher because I only touched ZF like 3 months ago. But I think it is a good & scalable idea, It should be a better architecture solution than ViewHelper.

    Cheers

  12. #12 by Actionstack is not evil on April 1, 2009 - 9:05 pm

    Hello,

    Actively developing with zf you can’t avoid hearing this over and over again, people compalining about the actionstack. I understand that you CAN make partials and views that render and fetch different stuff from the models. However, to create trully modular components, actionstack is a logical way to go (if actionstack really is such a bottleneck for performance maybe it should be made lighter).

    I have created an architecture which has dynamic modules that belong to some zone in a layout. The actionstack is used to make all the modules render themselves with their indexaction. For this reason I could just take that module and only use it solo because in indexaction it only echoes it’s own content. If you are using view scripts to also display actions of several modules in your page it is not really modular. I don’t know if you understand what I’m saying and I do get that actionstack gives overhead but it is still the thing that makes my modules the most logical I can have them.

    One thing though, I have never found the need for the action view helper and can’t really see a real use case for that one :)

    Cheers

  13. #13 by Chris on May 8, 2009 - 3:55 am

    I am torn. I am new to Zend Framework and have just discovered the Action View Helper. It seems to be exactly what I was looking for (except that I couldn’t figure out how to change the view that is rendered).
    I love the Action View Helper because model data need not be prepared again and again and again (I’m surprised that nobody here is more adamantly opposed to the fact that, with all of the aforementioned suggestions, you have to prepare model data over and over!).

    I am aware of the performance hit and am concerned (Hell, even Zend is saying not to use it!!!). Is there any way to embed mycontroller::myaction::myactionview in a view but not have to reprepare model data that is already prepared in mycontroller::myaction?

  14. #14 by sas171 on June 4, 2009 - 2:02 pm

    OK, I’ve done some banchmarking and found out, that calling a partial takes only 5% of the time that action view helper takes to call an action. Which means partial() is 20 times faster as action().

    Despite this results I think the best thing is to allow the developer to choose between actions and just view scripts. If he needs the flexibility of controller action than he will be OK with the perfomance hit for calling it.

  15. #15 by Mon Z. on June 7, 2009 - 3:16 am

    How about the controller method $this->_forward()? The action stack is basically _forward(), just deferred until Plugin::postDispatch(). I think the dispatch looping is a central part of the Zend MVC design. You are merely using the framework as it is designed when you use _forward and the action stack. If the dispatch isn’t supposed to loop, then the do-while shouldn’t be there! So I’d say both are perfectly fine, although the action stack plugin could use some trimming down (e.g. I don’t see the point of using the registry or Zend_Controller_Request_Simple when an instance member and arrays are perfectly fine).

    The action view helper is totally different though. I agree that it has to go.

  16. #16 by Bruno on June 29, 2009 - 1:16 pm

    Good one!

    This kind of article is very useful for initiationby the fact of Zend’s hard first steps and newcomers without such experience are tempted to use this features.

    Hail!

  17. #17 by Martin on August 4, 2009 - 8:08 am

    Hi all! Nice article. But I have similar problems as “Actionstack is not evil ” described.
    Let’s say, I have some calendar widget (fro simplicity assume that it is without AJAX). This widget allows some simple actions (hey, I called them ACTIONS, so they ask for some actionController!) like viewing next month or smth. like that. But this widget also has a link which allows calendar to open in full view so you can edit it – maybe mark your work schedule or smth like that. So to avoid having my calendar widget parts scattered around I guess I just HAVE TO keep everything calendar related in one place. And as I need some editing and full view abilities, so I just NEED calendar controller with different actions for editing in full view or using it as a small widget.

    It would be strange to implement full view as a controller but small view as a view helper, wouldn’t it? Especially because this calendar in my case is dynamic – not every logged-in user needs it so I HAVE TO GO through some other mechanism to find out if current user has permission and need to load some particular widget. And all these widgets are registered in some database table to know who can load them and in which part of layout they should be displayed.

    Anyway, also each widget needs some shared code to find out if someone is logged in and alos to find out what rights current user has for this widget – view only, edit own, view other persons calendars and so on.

    I agree, that it is bad to have action stack dispatching happening many times. So, how should I organize all this in my case with a calendar when I need a separate controller for calendar anyway?

    Thanks for any ideas.

  18. #18 by RiotRick on October 9, 2009 - 4:19 pm

    Indeed actionstack is not evil. It is extremely useful in certain applications.

    Basically we have done something similar as in reply #14.

    Divided a page into seperate blocks (using Zend_Layout). Each block can display content which is provided by a content provider module. This content provider module is created as a module in ZF with it’s own MVC structure.

    So basically this way we can create independent modules with their own mvc structure, which can be shared among different websites.

    We can add different modules to different layout blocks on the page.

    In order to run and render all these blocks we loop through all defined blocks on a page and run the linked module/controller/action with the action stack.

    Sure this will give a bit overhead, but it makes life a lot easier in developing seperate re-usable content modules.

  19. #19 by Christian on December 4, 2009 - 10:58 am

    I know this post is quite old, but I stumbled on this discussion when solving an ActionStack issue.

    I agree with the ActionHelper but I totally disagree regarding the ActionStack. If you are developing reusable components like mentioned in some earlier posts the ActionStack is an essential part of it. Why?

    Let’s think of a simple action “listArticles” and of a webpage consisting of 50+ pages where on each page a specific set of articles is to be displayed. The action itself may parameterized by: the number of articles to display, the category where the articles originate from and so on…

    Now, you end up with the situation, that you need to define *somewhere* which articles to display on a requested page and *where* on the page.

    There are several solutions:

    (1) Have one pageAction which is always called for rendering a page. The pageAction reads the configuration of the page from e.g. an xml file or from database

    (2) Have a PageController Plugin which hooks into routeShutdown() and builds up an *ActionStack* from an xml file or database

    (3) Have an action for each concrete page (pretty bad idea)

    In case (1) the “pageAction” would compile a concrete view template for the requested page – one for each page – as each page looks different in our case. Each view template would consist of one or several partials that query directly on the model. Now, you have the logical part of “what model data to display” in a view template?? Even if you parameterize the partial via view variables you still “hard code” that you want do display articles at exactly this position in the view script. Of course, if you work with Zend_Layout, you may alter the position, but still the logic of “what to display” is hard coded in the page template (and it’s one out of 50 templates if you remember)

    (2) If you work with a plugin that makes use of the Action Stack you work completely view independent. At routeShutdown() you can compile (via xml or db) a set of actions to render for this concrete page (e.g. 3 x list articles, 1 x navigation, 1 x newsletter subscription, …) – each with different parameters of course. In this case, an action is seen as an reusable component – reusable within a page and reusable on several pages. You can even load the position (layout target) and the to-be-used template via configuration. For the listArticlesAction you may have several templates to choose from: simple / extended / blogstyle – but all this is controlled via configuration, not in a controller or a view partial. Further more, you can specify the layout target when using Zend_Layout. This way it’s possible to render an action and it’s view into a specific position defined only via configuration.

    (3) I won’t argue on that one :)

    Feel free to comment on these thoughts – maybe I couldn’t state my point clearly. An example which is build upon (2) is our financial portal: http://www.godmode-trader.de/

    Obviously, the “PageController” concept collides with a simple MVC setup in this case. I would be happy about any other suggestions how to solve such requirements efficiently with Zend_MVC.

  20. #20 by Tehla on December 9, 2009 - 10:05 pm

    Hi,

    Thanks for your comments Christian, but what do you mean by “the layout is controlled via configuration” ? An .ini file ? Where do these settings (?) come from ?

    I’ m a beginer in ZF, and I ‘m looking for the best way to use ZF with on multi-widget site. And especially by ActionStack ^^

  21. #21 by Ryan Mauger on December 16, 2009 - 10:22 am

    Actually Christian, There are far more solutions that the three you outlined, and the three you have, are pretty terrible imo.
    An action should actually *do* something useful. The thought of using an action just to fill one small chunk of a page makes me shudder at best.
    To make widgetised content the best solution is by far to create a view helper for each widget, which can then render a partial after passing it content from the db. this gives the nice seperation of concerns, while avoiding having the dispatch loop bounce around creating masses of extra opportunities for bugs, making it hard to see the execution flow directly, and loads of extra overhead.
    Also note, if you need a different template for each page, you are working very inefficiently. You should be able to manage your articles to be displayed on a particular page without the need of a template for each permutation, and it should also be possible to do this without hardcoding this into the template. Infact I would go so far as to say that if you require this many templates for your pages, then you have simply hardcodeded this elsewhere, shifting it, rather than eliminating it.

  22. #22 by Dan Moore on February 2, 2010 - 3:22 am

    I’m a noob to Zend, is the Action View Helper the thing that takes controller/action and finds the corresponding view script in the views directory and echoes it? (or includes it in the site wide layout as ->content)

  23. #23 by admin on February 18, 2010 - 8:10 pm

    Dan: Sorry, the action view helper does much more than this, it grabs the request, and dispatcher from the front controller, and clones them, then dispatches a whole new request to run the actual action your asking for. its a terrible waste! (and will include a layout if your not careful)

  24. #24 by David on April 15, 2010 - 10:38 am

    So you advise to use an MVC pull approach ?

  25. #25 by Mangled on August 11, 2010 - 9:30 am

    View helpers are great. It’s great to have a NewsController and be able to have some lightweight view helpers to be able to render some breadcrumbs, a menu or a shopping cart.

    But what if you have fully dynamic pages, loaded from a database? Where there is no NewsController, because “news” is just one of the widgets that can be placed on a page? What if every widget has it own request parameters/configurations, differing from page to page? What if you want every widget in an individual directory, with it’s own models and views?

    Currently, Zend Framework has no better way than to achieve this with routes to some IndexController, or “PageController”, and the actionstack to execute each widget, one by one, until the page is fully built.

  26. #26 by Ryan on August 11, 2010 - 9:44 pm

    Actually, there are plenty of better ways to achieve this, and I would say that the actionstack is about the worst. All you are suggesting, is that you put all the presentation logic (which blocks to render where) into your controller.

    That logic of deciding which blocks to place where belongs squarely in the view, and not in your controller.
    If each block (or widget) needs its own configuration, it is perfectly acceptable within MVC for the view to fetch this directly from the model, no need for a controller just for that.

    Remember, your controller is for steering your request, NOT for deciding how things should look.

  27. #27 by Jake Noble on August 21, 2010 - 3:02 pm

    Great article. Negative, but well explained and completely justified!

  28. #28 by Anonymous on November 23, 2010 - 6:14 pm

    Cristian :
    I am investigating also some ways to avoid using ActionStack for widgetized content to see what effective options we have. I am trying to put some very simple sample cases.
    1. Using view->render
    Into action controller prepare data for those areas and set it to view: $this->view->data = LoadDataFromModel.
    Then on view we are simply making a $this->render(‘widgetA.phtml’), and widgetA.phtml makes use of data supplied to view;
    This is probably the fastest into processing terms, no helper used.
    2. Using view->render with layout & response segments
    Let’s suppose on Layout we have two zones, zone1, and zone2 with witgetized content (data from some diff sources).
    layout()->zone1?>
    layout()->content?>
    layout()->zone2?>
    Into action controller prepare data for those areas and set it to view $this->view->data = $data_from_model.
    Then:
    $response = $this->getResponse();
    $response->insert(‘zone1′, $this->view->render(‘widget1.phtml’));
    $response->insert(‘zone2′, $this->view->render(‘widget2.phtml’));
    Advantage of this methos would be the fact that is adapted to use of layouts.
    3. Using view helpers without layout – fixed widgets
    This is similar as 1, just that:
    - Instead of $this->render(‘widgetA.phtml’) we are calling helper: $this->widgetA(….)
    - Data is loaded by helper, not on action
    I said fixed widgets because in such case the widget call is hardcoded into a specific template, so we won’t really have the option to use diff widgets on same position depending on case
    3. Using view helpers without layout – dynamic widgets
    This is similar with3, just that:
    - Instead of calling $this->widgetA(….) we are calling $this->widget(….)
    - $this->widget(….) dynamically select the proper widget to call and it returns his return result
    5. Using view helpers with layouts
    This is similar as 2, just that on action we have something like that
    $response = $this->getResponse();
    $response->insert(‘zone1′, $this->view->widgetA());
    $response->insert(‘zone2′, $this->view->widgetB());
    And of course, we can automatically select the widget to be called.
    Might be other ways, i just tried to make a list to see choices…

  29. #29 by Ethan Fremen on December 16, 2010 - 5:30 pm

    So … the primary reason I’d gone with the action stack is it allows components of the page to be provided via json (where they will be a full request) or included in the page on load, “without changes”.

    What it seems *would* make sense is for there to be some way to know you are in a “sub request” and thus bail out of a lot of the initialization that happens.

    ~ehtan

  30. #30 by sims on January 16, 2011 - 8:46 am

    I just want to make sure the point of this post is not “actions” are evil. I was a bit confused by “Actionstack” I’ve never used the action view helper because I thought it was a pretty lame band aid. What is referred to by “actionstack”? Links to docs would be nice.

  31. #31 by rvdavid on January 28, 2011 - 6:09 pm

    @sims Actions are most certainly _not_ evil. The topic of this is an ActionHelper component called “ActionStack” which is documented in the manual; here’s the link:

    http://framework.zend.com/manual/1.11/en/zend.controller.actionhelpers.html

    HTH

  32. #32 by Cris on February 23, 2011 - 11:55 pm

    Consider the following:
    I am using different layout()->blockX to render independent content besides the main layout()->content.
    One of those independent blocks has, for the sake of keeping it simple, 15 lines of code.

    With actionstack I can use ONE action dedicated to that block which handles all the code needed to render its view.

    Now how would you go about using something else then actionstack to render that block along with the main content without having to write those 15 lines of code (that are only written once! when using actionstack) in EVERY action or controller init where I want to render said block?
    Also consider that the block in question is like a switch, in 50% of pages i need viewX for the same block and in the remaining viewY (just to make a point here).

    Until recently I used render, renderScript and the partial view helper and from my 16 month experience with zend none are as elegant as actionstack.
    Just:
    actionstack(nav,nav)
    actionstack(filters,filters)
    actionstack(cart,cart)
    actionstack(search,search)

    and all thats left is the main content. Can’t say I’ve noticed any performance changes.

  33. #33 by Dimitri on August 15, 2011 - 5:13 am

    Actionstack is not evil :
    Hello,
    Actively developing with zf you can’t avoid hearing this over and over again, people compalining about the actionstack. I understand that you CAN make partials and views that render and fetch different stuff from the models. However, to create trully modular components, actionstack is a logical way to go (if actionstack really is such a bottleneck for performance maybe it should be made lighter).
    I have created an architecture which has dynamic modules that belong to some zone in a layout. The actionstack is used to make all the modules render themselves with their indexaction. For this reason I could just take that module and only use it solo because in indexaction it only echoes it’s own content. If you are using view scripts to also display actions of several modules in your page it is not really modular. I don’t know if you understand what I’m saying and I do get that actionstack gives overhead but it is still the thing that makes my modules the most logical I can have them.
    One thing though, I have never found the need for the action view helper and can’t really see a real use case for that one
    Cheers

    Hello My Friend,
    Can you tell me how did you do that?
    How to echoes layouts->widgetized with the calling name of a nameAction?

  34. #34 by Judy on August 15, 2011 - 4:18 pm

    Kieran said:

    Well said. When I started out with ZF I encountered the Actionstack, and a whole load of problems – many of which you touch on.

    I couldn’t agree more. I got a boatload of probs when I first started using Zend and the Actionstack. You touched on many of those issues. Just clarifies my thoughts on things…..

Comments are closed.