repo_zf1/documentation/manual/en/module_specs/Zend_View-Abstract.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- Reviewed: no -->
<sect1 id="zend.view.abstract">
    <title>Zend_View_Abstract</title>

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

    <para>
        Many developers find that they want to extend
        <classname>Zend_View_Abstract</classname> 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.
    </para>

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

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

    <programlisting language="php"><![CDATA[
protected function _run()
{
    include func_get_arg(0);
}
]]></programlisting>

    <para>
        As such, the view scripts have access to the current object
        (<varname>$this</varname>), <emphasis>and any methods or members of that
            object</emphasis>. 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 <varname>$_path</varname> or
        <varname>$_file</varname> inadvertently -- any further calls to
        <methodname>render()</methodname> or view helpers would break!
    </para>

    <para>
        Fortunately, <acronym>PHP</acronym> 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
        <classname>Zend_View</classname> <emphasis>extends</emphasis>
        <classname>Zend_View_Abstract</classname>, view scripts are thus limited to only
        protected or public methods and members of
        <classname>Zend_View_Abstract</classname> -- effectively limiting the actions it
        can perform, and allowing us to secure critical areas from abuse by view
        scripts.
    </para>
</sect1>
<!--
vim:se ts=4 sw=4 et:
-->