Zend Framework Components Part 2: Zend_View

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
{
private $view;
function __construct()
{
$this->view = new Zend_View();
$this->view->setScriptPath(‘../application/views/scripts’);
}

/*
* Run at the beginning of the controller’s response object initialization
*/
public function preDispatch( Zend_Controller_Request_Abstract $request )
{
$this->getResponse()->prepend(‘header’,$this->view->render(‘header.phtml’,null,true));
}
/*
* Run at the end of the controller’s response object initialization
*/
public function postDispatch( Zend_Controller_Request_Abstract $request )
{
$this->getResponse()->append(‘footer’, $this->view->render(‘footer.phtml’,null,true));
}

}

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.
$controller->registerPlugin(new LayoutPlugin());
$controller->dispatch();

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!