View Source

<h1>Zend_View 2.0 Notes on development</h1>

<h2>Update to use PluginLoader</h2>

<p>Currently, Zend_View uses its own system for managing plugins. This leads to issues when branching Zend_View, as well as to inconsistencies with the rest of the framework. It needs to be adapted to use Zend_Loader_PluginLoader for better consistency, to adhere to the DRY principle, and to allow for custom Plugin Loading solutions for helpers and filters.</p>

<p><strong>Note:</strong> this is currently done in the incubator.</p>

<h2>Allow optional use of streams to emulate short_open_tags on systems where it is disabled</h2>

<p>Currently, there's some confusion regarding the use of short_open_tags with ZF.<br />
Our coding standards dictate using full &lt;?php tags at all times, but our<br />
documentation utilizes short tags for view scripts.</p>

<p>The recommendation all along is that library code should utilize fully qualified<br />
tags, but that view scripts can and should use short tags for brevity and<br />
clarity.</p>

<p>Unfortunately, current versions of PHP only allow setting short_open_tags at PER_DIR or stricter levels &ndash; and the php.ini-recommended disables it entirely, which means it is often disabled on end user systems.</p>

<p>Fortunately, we can emulate short_open_tags using stream wrappers. Adding this capability to Zend_View &ndash; and the option to disable it &ndash; would offer a flexible solution in line with our examples and messaging.</p>

<p><strong>NOTE:</strong> this is currently done in the incubator.</p>

<h2>Automatic escaping of view variables</h2>

<p>One criticism of Zend_View is that it makes it difficult to escape variables, which does not encourage good security. One easy change would be to simply have all variables retrieved via __get() be escaped by default, and instead require developers to call a special method when they want the raw value.</p>

<p>This will not help in all situations &ndash; return values from view variable method calls or properties, or values from arrays would not be escaped in this fashion. An enhanced stream wrapper could solve this issue.</p>

<h2>Helper Interface and Abstract</h2>

<p>Currently, it's not entirely clear that you have to implement setView() in your helpers to have view awareness. Additionally, the naming conventions often get in the way, and don't follow best practices ala design patterns. The recommendation is to have a helper interface like this:</p>

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
interface Zend_View_Helper_Interface
{
public function setView(Zend_View_Interface $view);
public function getView();
public function direct(); // method called when helper invoked
}
]]></ac:plain-text-body></ac:macro>

<p>Additionally, an abstract class implementing this would be created:</p>

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
abstract class Zend_View_Helper_Abstract implements Zend_View_Helper_Interface
{
public $view;

public function setView(Zend_View_Interface $view)
{
$this->view = $view;
return $this;
}

public function getView()
{
return $this->view;
}
}
]]></ac:plain-text-body></ac:macro>

<p>Helpers would then extend the abstract class and implement the direct() method as necessary.</p>

<h2>Revisit Zend_View_Interface</h2>

<p>Zend_View_Interface aims to make it simple to wrap alternate view implementations and retain compatibility with ZF components. However, there are some places where this falls apart: Zend_View helpers, for instance, are very useful and in some cases providing convenience features not found in other templating systems, but may not work with an alternate implementation. We should explore ways of making helpers work with such implementations.</p>

<h2>Examine the usage of Zend_Registry for view variables</h2>

<p>By using a registry for view variables, we would achieve a greater separation of concerns within Zend_View. Currently, much care needs to be taken when using Zend_View as a view &quot;engine&quot; and when it is being used as a view script &quot;variable store&quot;. By using $<em>registry = new Zend_Registry() (in the standard, lazy-loaded, accessor driven way), we gain this separation of concerns. __get()/</em>_set() would need to proxy to this registry. This also would allow the ability to drop context of view script variables..</p>

<p>Matthew R. also talks about context in this bug:</p>

<p><a href="http://framework.zend.com/issues/browse/ZF-3166">http://framework.zend.com/issues/browse/ZF-3166</a></p>