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.

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.

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.