Zend MVC Page Structure & Layout Link's Paths

Go To StackoverFlow.com


I have a working zend mvc application that is using a layout, and this layout uses external stylesheets and scripts. Each page in the site has it's own controller, and the page-specific content for each page is in its index.phtml file. The layout works, and all the scripts/stylesheets are properly applied for each controller's index.phtml.

For example, the home page is "mvcProject/" which calls the index controller's index action which uses the index.phtml file respective to the index controller. Futhermore, the about us page is "mvcProject/about" which calls the about controller and displays views/about/index.phtml. Subjectively I felt that this structure was inefficient. The content of this site is only html, and I can't see why each page needs its own controller.

Therefore I tried to use only one controller to achieve the same end, that is to have the same architecture, by giving each page its own action within the single index controller. So now the "about us" page was "mvcProject/index/about" so that the index controller would call the about action which would use the views/index/about.phtml file.

This approach broke all of the links to external scripts/stylesheets in the layout. The layout still worked, but none of the links' paths would work. Obviously, this is a path-related issue, but I'm still relatively new to zend so I wasn't sure how to fix this. Therefore I went back and gave each page it's own controller again.

So my question is two fold: do I need concern myself with avoiding the bloat of giving each page its own controller, and if I do need to slim this structure down, what do I need to adjust to correct the links' paths? Thanks for your consideration.

2012-04-03 22:54
by dsulli
You're using the Zend framework to serve only HTML content, no database, nothing dynamic? Seems like overkill to be using this framework for this task let alone thinking a controller for each page is overkill. It is not overkill to give each page it's own controller. This is what MVC is for, you route a request to a controller to deal with, the controller will then return a response. This is the whole idea. look at this question about serving static content in the Zend_Framework (http://stackoverflow.com/questions/8946486/updated-best-practices-for-managing-static-content-in-zend-framework - Flukey 2012-04-03 22:57
Agreed, this would be overkill for static content alone. However, this is just phase one of a much larger project. In a week or two I'll be adding the databases. Thanks for the link - dsulli 2012-04-22 07:31


Ignoring the discussion about the framework/number of controllers is overkill for now. The reason your scripts/css are failing is indeed a path issue. If you are using the layout helper then you should make use of the headLink and headScript objects inside the view.

This is my preferred way of setting up the scripts and css files I need whilst developing.


protected function _initView()
    // Initalise the view
    $view = new Zend_View();

    // Get config options for the UI
    $ui = $this->getApplication()->getOption('ui');


    foreach ($ui['stylesheet'] as $stylesheet) {

    foreach ($ui['script'] as $script) {

    $viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper(

    return $view;


ui.title = "My Awesome Web App"
ui.stylesheet[] = "/extjs/resources/css/ext-all.css"
ui.stylesheet[] = "/resources/css/hod.css"
ui.stylesheet[] = "/resources/css/icons.css"
ui.stylesheet[] = "/resources/bootstrap/css/bootstrap.css"
ui.script[] = "extjs/ext-debug.js"
ui.script[] = "app.js"


<?php echo $this->doctype(); ?>
    echo $this->headTitle();
    echo $this->headMeta();
    echo $this->headStyle();
    echo $this->headScript();
    echo $this->headLink();

    <?php echo $this->layout()->content; ?>

This allows you to setup all the scripts you need in development mode, and set the minified scripts in production all in the config without having to write any extra code.

Going back to the overkill question. I think even if you don't have connections to the database and all the bells and whistles in your app, using a framework is still the best approach from a maintenance point of view (once you're up to speed with the framework that is) if you are going to have more than 5 or 6 pages. Unless your website is going to see huge volumes of traffic and every byte or ms counts, then I don't see the point in reducing maintainability for the small overhead a framework adds.

The same logic applies for me with controllers. I don't see why you want to reduce the number of them when they help clearly split up the functions of work. Plus unless you change the router site.com/index/about looks uglier than site.com/about :)

2012-04-03 23:28
by Jamie Sutherland
Separately handling development and production environments' resources. That's slick. Thanks. You answered a question that I didn't even know I had. Thanks for your help - dsulli 2012-04-04 01:14
No problem, Added an edit to include the lines needed in the layout script as I missed that part in case anyone else comes along and read it - Jamie Sutherland 2012-04-04 07:51


I'm not sure how your path and url are created in your views, but do you use the baseUrl helper ? $this->baseUrl( [file] )

2012-04-04 08:34
by conradfr