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 ^^

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.

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.

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.

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!