Zend_View_Abstract is the base class on which Zend_View is built; Zend_View itself simply extends it and declares a concrete implementation of the _run() method (which is invoked by render()).

Many developers find that they want to extend Zend_View_Abstract to add custom functionality, and inevitably run into issues with its design, which includes a number of private members. This document aims to explain the decision behind the design.

Zend_View is something of an anti-templating engine in that it uses PHP natively for its templating. As a result, all of PHP is available, and view scripts inherit the scope of their calling object.

It is this latter point that is salient to the design decisions. Internally, Zend_View::_run() does the following:

protected function _run()
{
    include func_get_arg(0);
}

As such, the view scripts have access to the current object ($this), and any methods or members of that object. Since many operations depend on members with limited visibility, this poses a problem: the view scripts could potentially make calls to such methods or modify critical properties directly. Imagine a script overwriting $_path or $_file inadvertently -- any further calls to render() or view helpers would break!

Fortunately, PHP 5 has an answer to this with its visibility declarations: private members are not accessible by objects extending a given class. This led to the current design: since Zend_View extends Zend_View_Abstract, view scripts are thus limited to only protected or public methods and members of Zend_View_Abstract -- effectively limiting the actions it can perform, and allowing us to secure critical areas from abuse by view scripts.