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:
<?php
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.