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.
Note: this is currently done in the incubator.
Currently, there's some confusion regarding the use of short_open_tags with ZF.
Our coding standards dictate using full <?php tags at all times, but our
documentation utilizes short tags for view scripts.
The recommendation all along is that library code should utilize fully qualified
tags, but that view scripts can and should use short tags for brevity and
Unfortunately, current versions of PHP only allow setting short_open_tags at PER_DIR or stricter levels – and the php.ini-recommended disables it entirely, which means it is often disabled on end user systems.
Fortunately, we can emulate short_open_tags using stream wrappers. Adding this capability to Zend_View – and the option to disable it – would offer a flexible solution in line with our examples and messaging.
NOTE: this is currently done in the incubator.
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.
This will not help in all situations – 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.
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:
Additionally, an abstract class implementing this would be created:
Helpers would then extend the abstract class and implement the direct() method as necessary.
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.