The Zend Framework in Practice

As well as writing a completely new resource plugin to use with Zend_Application, it is also possible to write a plugin that replaces one of the standard ones. The reason for doing this is that the existing plugins sometimes don’t do all the things that you want them to.

Zend_Application_Resource_View is a common plugin to replace. This is because it doesn’t allow you to set the DOCTYPE. The sample application contains a replacement for this plugin, which sets this, among other things.

Default_Resource_View has the following basic skeleton:

class Default_Resource_View
  extends Zend_Application_Resource_ResourceAbstract
{
  // Add class methods and variables here
}

Zend_Application_Resource_ResourceAbstract is the base class, as is required.

A variable is declared to store the Zend_View:

protected $_view;

Zend_Application will call the init method of the class to retrieve the resource it initialises. The class uses the singleton pattern to implement this.

First, the init method is declared; this in turn calls the getView method, which will create the Zend_View if necessary:

public function init()
{
  return $this->getView();
}

The getView method starts by checking whether the Zend_View has already been created; if not, it gets the options from the configuration file and creates the view:

public function getView()
{
  if (null === $this->_view)
  {
    // Get the resource options
    $options = $this->getOptions();
 
    // Create the view
    $view = new Zend_View();

The method then checks whether the doctype option is set; if it is, it sets the view’s doctype to the specified value:

    // Set the doctype
    if (isset($options['doctype']))
    {
        $view->doctype($options['doctype']);
    }

This option is set as follows in the sample application:

resources.view.doctype = "XHTML1_STRICT"

The next option to check is the helpers option; this allows the application to add view helper paths to the view; these specify the possible prefixes and locations of view helper classes:

    // Add the custom view helper paths
    if (array_key_exists('helpers', $options))
    {
      foreach ($options['helpers'] as $key => $value)
      {
        $view->addHelperPath($value, $key);
      }
    }

The view helpers are declared as key/value pairs in the configuration file; the prefix is the key and the location the value:

resources.view.helpers.Default_View_Helper = 
  APPLICATION_PATH "/views/helpers"
resources.view.helpers.ZendX_JQuery_View_Helper = 
  "ZendX/JQuery/View/Helper"
resources.view.helpers.Test_View_Helper = 
  APPLICATION_PATH "/tests/helpers"

The first set of helpers are the generally-used helpers defined by the application; the second set are those in the Zend extras jQuery module; the third set are used exclusive to the test controller. We shall see examples of these in use in later posts.

The last option is placeholders. These are pieces of text that are used in more than one place in the layout and view scripts, and which may need to be changed, such as the contact phone number. They are defined in the configuration file as key/value pairs:

    // Add the placeholders
    if (array_key_exists('placeholders', $options))
    {
      foreach ($options['placeholders'] as $key => $value)
      {
        $view->placeholder($key)->set($value);
      }
    }

The following placeholders are defined in the configuration file:

resources.view.placeholders.phoneNumber = "+44 (0)1403 753721" 
resources.view.placeholders.copyrightDate = "2009"

Finally, the Zend_View is attached to the View Renderer and a reference to it is stored in $_view:

    // Set the view renderer to use the view
    $viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper
      ('ViewRenderer');
    $viewRenderer->setView($view);
 
    $this->_view = $view;
  }

That ends the block that is executed when a Zend_View does not yet exist. At this point, a Zend_View has been created, and the reference to this is returned from the method:

  return $this->_view;
}