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

   1 <?xml version="1.0" encoding="UTF-8"?>
   2 <!-- Reviewed: no -->
   3 <sect1 id="zend.view.abstract">
   4     <title>Zend_View_Abstract</title>
   5
   6     <para>
   7         <classname>Zend_View_Abstract</classname> is the base class on which
   8         <classname>Zend_View</classname> is built; <classname>Zend_View</classname> itself simply
   9         extends it and declares a concrete implementation of the
  10         <methodname>_run()</methodname> method (which is invoked by
  11         <methodname>render()</methodname>).
  12     </para>
  13
  14     <para>
  15         Many developers find that they want to extend
  16         <classname>Zend_View_Abstract</classname> to add custom functionality, and
  17         inevitably run into issues with its design, which includes a number of
  18         private members. This document aims to explain the decision behind the
  19         design.
  20     </para>
  21
  22     <para>
  23         <classname>Zend_View</classname> is something of an anti-templating engine in that
  24         it uses <acronym>PHP</acronym> natively for its templating. As a result, all of
  25         <acronym>PHP</acronym> is available, and view scripts inherit the scope of their calling
  26         object.
  27     </para>
  28
  29     <para>
  30         It is this latter point that is salient to the design decisions.
  31         Internally, <methodname>Zend_View::_run()</methodname> does the following:
  32     </para>
  33
  34     <programlisting language="php"><![CDATA[
  35 protected function _run()
  36 {
  37     include func_get_arg(0);
  38 }
  39 ]]></programlisting>
  40
  41     <para>
  42         As such, the view scripts have access to the current object
  43         (<varname>$this</varname>), <emphasis>and any methods or members of that
  44             object</emphasis>. Since many operations depend on members with
  45         limited visibility, this poses a problem: the view scripts could
  46         potentially make calls to such methods or modify critical properties
  47         directly. Imagine a script overwriting <varname>$_path</varname> or
  48         <varname>$_file</varname> inadvertently -- any further calls to
  49         <methodname>render()</methodname> or view helpers would break!
  50     </para>
  51
  52     <para>
  53         Fortunately, <acronym>PHP</acronym> 5 has an answer to this with its visibility
  54         declarations: private members are not accessible by objects extending a
  55         given class. This led to the current design: since
  56         <classname>Zend_View</classname> <emphasis>extends</emphasis>
  57         <classname>Zend_View_Abstract</classname>, view scripts are thus limited to only
  58         protected or public methods and members of
  59         <classname>Zend_View_Abstract</classname> -- effectively limiting the actions it
  60         can perform, and allowing us to secure critical areas from abuse by view
  61         scripts.
  62     </para>
  63 </sect1>
  64 <!--
  65 vim:se ts=4 sw=4 et:
  66 -->