# 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.