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
$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!