By: Jon Lebensold
As part of a series of articles about the Zend Framework and MVC, I’d like to take some time and cover Zend_View (the ‘V’ in that MVC triad).
Within the Zend Framework architecture and documentation, Zend_View is often coupled with the Zend_Controller as a means of providing a templating engine that encourages smart defaults over explicit programming.
For example, if I have a Controller named ‘AccountsController’ with an action (AKA a method that ends in ‘Action’ inside the AccountsController) called “new”, this would be mapped to the url “mydomain.com/Accounts/new”.
After running whatever is found inside AccountsConroller::newAction(), the Zend_Controller would be clever enough to dig out of my application/views/scripts folder, the Accounts/new.phtml file as a template for the action in question.
This sounds great at first, however you’ll find yourself adding:
< ? php include 'scripts/header.php'; ?>
… to the top and:
< ? php include 'scripts/footer.php'; ?>
… to the bottom of every phtml file! This breaks the DRY principle (Don’t Repeat Yourself!) which leads us to…
Creating a Standard Layout for all Zend_Views Loaded by Zend_Controller
The default behaviour of Zend_Controller is actually handled by the Zend_Controller_Front class, which then routes and loads the appropriate Controller in your application. In order to inject a custom template, we need to do three things:
1- Write a Layout Plugin
2- Create our beautiful layout
3- Register the plugin
The LayoutPlugin is a piece of cake, especially since I’ve written a class that can be implemented in any project:
* Handles the header / footer by capturing the preDispatch and postDispatch of the
* response object
class LayoutPlugin extends Zend_Controller_Plugin_Abstract
$this->view = new Zend_View();
* Run at the beginning of the controller’s response object initialization
public function preDispatch( Zend_Controller_Request_Abstract $request )
* Run at the end of the controller’s response object initialization
public function postDispatch( Zend_Controller_Request_Abstract $request )
The interesting parts of this class are setScriptPath() , prepend() and append(). Essentially, the Zend Plugin architecture is expecting preDispatch and postDispatch to be available in any plugin that’s injected into the Front_Controller.
What we’re basically doing is telling Zend_Front_Controller to prepend ‘header.phtml’ and append ‘footer.phtml’ to all of our pages. We could get fancier by pulling a variable from our registry that would affect which header and footer is loaded (see my previous blog post for a sample of how to use Zend_Registry).
Step 2 is adding ‘header.phtml’ and ‘footer.phtml’ to your application/views/scripts/ folder with their respective headers and footers. Personally, I like to start my websites either with an open source template from LayoutGala or Webshapes so that I have a good structural starting point for my application.
Step 3 is simply registering the component. In your index.php, assuming you’ve setup Zend_Loader to register classes automatically, one line of code needs to be added after Zend_Front_Controller is declared:
$controller = Zend_Controller_Front::getInstance();
// add the following to register our newly-created layout plugin.
In my next post, I’ll cover using Zend_View without Zend_Controller. This will lead up to creating custom View Helpers that can then be loaded dynamically through your PHP AJAX framework of choice!
This entry was posted on Monday, January 14th, 2008 at 11:13 pm and is filed under Zend-Framework. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.