View Helpers | Zend_View Programmer's Reference Guide | Zend_Wildfire
# Zend_View_Abstract 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.
View Helpers | Zend_View Programmer's Reference Guide | Zend_Wildfire