Become Zend Certified

Prepare for the ZCE exam using our quizzes (web or iPad/iPhone). More info...

When you're ready get 7.5% off your exam voucher using voucher CJQNOV23 at the Zend Store

View Integration

Default View Integration is Via the ViewRenderer

The content in this section is only valid when you have explicitly disabled the ViewRenderer. Otherwise, you can safely skip over this section.

Zend_Controller_Action provides a rudimentary and flexible mechanism for view integration. Two methods accomplish this, initView() and render(); the former method lazy-loads the $view public property, and the latter renders a view based on the current requested action, using the directory hierarchy to determine the script path.

View Initialization

initView() initializes the view object. render() calls initView() in order to retrieve the view object, but it may be initialized at any time; by default it populates the $view property with a Zend_View object, but any class implementing Zend_View_Interface may be used. If $view is already initialized, it simply returns that property.

The default implementation makes the following assumption of the directory structure:


In other words, view scripts are assumed to be in the /views/scripts/ subdirectory, and the /views/ subdirectory is assumed to contain sibling functionality (helpers, filters). When determining the view script name and path, the /views/scripts/ directory will be used as the base path, with directories named after the individual controllers providing a hierarchy of view scripts.

Rendering Views

render() has the following signature:

string render
(string $action null,
string $name null,
bool $noController false);

render() renders a view script. If no arguments are passed, it assumes that the script requested is [controller]/[action].phtml (where .phtml is the value of the $viewSuffix property). Passing a value for $action will render that template in the /[controller]/ subdirectory. To override using the /[controller]/ subdirectory, pass a TRUE value for $noController. Finally, templates are rendered into the response object; if you wish to render to a specific named segment in the response object, pass a value to $name.


Since controller and action names may contain word delimiter characters such as '_', '.', and '-', render() normalizes these to '-' when determining the script name. Internally, it uses the dispatcher's word and path delimiters to do this normalization. Thus, a request to / will render the script foo-bar/baz-bat.phtml. If your action method contains camelCasing, please remember that this will result in '-' separated words when determining the view script file name.

Some examples:

class MyController extends Zend_Controller_Action
    public function 
// Renders my/foo.phtml

// Renders my/bar.phtml

// Renders baz.phtml

// Renders my/login.phtml to the 'form' segment of the
        // response object

// Renders site.phtml to the 'page' segment of the response
        // object; does not use the 'my/' subirectory

    public function 
// Renders my/baz-bat.phtml

Zend Framework