1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
<?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:
-->
|
