Extending Zend_Controller_A...

Making the magic happen

Many other frameworks (like CakePHP, Symfony or Ruby On Rails) have a predefined directory structure that makes it very easy to just "drop in" new functionality. It is exactly defined where your controllers, actions and templates go and how they have to be named. This not only makes it very easy to find everything even months after you had taken the last look on your code, it also allows for nearly configuration-free operation of the framework. The Zend Framework gurus actually suggest such a standard directory structure, which looks like this: Nice and clean. There's only one problem: Except for the document_root (obviously), the "controllers" and "library" directories, they don't really make use of them. A basic function of most other frameworks is that you never have to define the path to your template or its filename. It is implicitly deduced from the current controller and action names. In your action methods you'd then be able to simply assign variables to the already existing template objects - nothing else. But one template is not enough - I need at least three of them! Three? Yes, three. Nested, actually. One outermost template for the basic application layout, one inner template for the current controller and one innermost template for the current action's output. The two outer templates are using special placeholders to specify where exactly the content of their child templates need to be placed. Having the application, controller and action templates separated means being able to easily change the look of the whole application just by changing the outermost template. The controller template saves you from repeating the same stuff (e.g. controller-wide navigation) over and over again in each of the action templates. To be able to use this kind of template hierarchy without having to specify anything by hand, a strict directory/naming convention needs to be followed. Within the views directory I have one directory for each controller, having exactly the same name as the controller (without the "Controller" postfix though). Inside each of these directories, there is one template file for each action, having the action's name plus the postfix "View" as its name. The controller template itself also lies within that directory, but is just called "Master". The outermost application template is named "ApplicationMaster" and is located just within the views directory. So for the above example URL, the following templates would be used: As you can see by the .php postfix, I like using Zend_View with its plain PHP templates. To make all this happen, I don't have to do a lot - since all Controller classes are derived from Zend_Controller_Action, I just have to subclass it, add a constructor to set up the Zend_View objects and a destructor to render their output when the script has finished and all the objects are being destroyed. My controller classes then just have to extend CWAC_Controller_Action and then have the new class properties _applicationView, _controllerView and _actionView available, which can immediately be used to assign template variables. To allow the output of bytestreams or XML data (e.g. for webservices), the property _noMasterViews can be set to true, which causes only the action view to be used.

Have a look at the source

I have set up a new subversion repository containing all CWAC components: https://ssl.limbourg.com/svn/CWAC/ Find the source of the CWAC_Action_Controller here: https://ssl.limbourg.com/svn/CWAC/trunk/library/CWAC/Controller/Action.php It is drop-dead simple, really, but makes working with the Zend Framework a lot more productive and fun. In fact, it is so simple one could ask why this wasn't built into the framework in the first place. There's only one valid answer that I can come with: To maintain the freedom of choice. It remains your choice which template engine to use, so you don't need to use Zend_View if you don't want to (and we all know how many religious wars have been fought over the best template engine...). And you don't need to conform to a given directory structure if it doesn't suit you. This flexibility is what I like most about the Zend Framework, even though it may make it look weak when directly compared to other frameworks' feature sets.