Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_View_Helper_Abstract Component Proposal

Proposed Component Name Zend_View_Helper_Abstract
Developer Notes
Proposers Jurriën Stutterheim
Zend Liaison Matthew Weier O'Phinney
Revision 1.0 - 11 June 2008: Initial Draft.
1.1 - 05 Aug 2008: Addition of direct() method. (wiki revision: 16)

Table of Contents

1. Overview

Zend_View_Helper_Abstract is a very simple abstract class for view helpers. It provides the setView() method and the public $view attribute. At the moment these two are being copy/pasted in every view helper that needs it. Most helpers however can just as easily take this abstract class as parent to save duplicate code.

Additionally a Zend_View_Helper_Interface could be added. It would contain the signature for the setView() method. This would allow for more complex view helpers, like HeadTitle, which already inherit from another class to be identified as well.

Finally, a long-term goal for view helpers is to remove the tedious and difficult to understand naming of the helper method and instead implement the strategy pattern: all helpers would use the same method name. This would simplify implementation of calling helpers within Zend_View, and make it easier to visually identify the method that does the helper work. The proposal is to use the method name 'direct', which is already currently used in action helpers and is a fairly standard name for use with the strategy pattern. In the short term, it would go un-used, but would be available for future compatibility.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will provide the basic setView() implementation for view helpers
  • This component will provide an interface with a setView() signature
  • This component will provide an interface with a direct() signature
  • This component will not implement any functionality around direct() at this time.

4. Dependencies on Other Framework Components

5. Theory of Operation

6. Milestones / Tasks

  • Milestone 1: [DONE] Prototype available
  • Milestone 2: [DONE] Unit tests available
  • Milestone 3: [DONE] Component checked into incubator
  • Milestone 4: [DONE] View helper documentation is updated
  • Milestone 5: [DONE] Component checked into core
  • Milestone 6: [DONE] Update the existing helpers to utilize these classes.

7. Class Index

  • Zend_View_Helper_Abstract
  • Zend_View_Helper_Interface

These classes should get another name, because of ZF's future adoptation of PHP 5.3 namespaces. See the link to Matthew's blog post in the references section. Suggestions:

  • Interface:
    • Zend::View::Helper::IHelper
    • Zend::View::Helper::Helper
  • Abstract:
    • Zend::View::Helper::HelperAbstract
    • Zend::View::Helper::Base

8. Use Cases


Would become:

This allows:

To be removed from the Form helper


Could become:


Currently helpers are checked if they have setView like so:

This can be done much nicer now:

Additionally, eventually instead of creating a formatted version of the helper method name, we will simply be able to call direct:

9. Class Skeletons



Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jun 11, 2008

    <p>I'm in on this as long as the base is an interface instead of an abstract class. This makes it possible to make view helpers extend other useful classes, and the same functionality as the abstract class is provided (basically).</p>

    1. Jun 11, 2008

      <p>The interface has been added to accompany the abstract class, as discussed on IRC.</p>

  2. Jun 16, 2008

    <p>I think this is a great idea. IMHO method_exists() checks should be phased out across all of ZF in favour of interfaces such as this.</p>

  3. Jun 24, 2008

    <p>Jurrien, this is a great idea, and one I've been plannning for some time. However, timing is bad. I feel that this could be a potential BC break, and would be timed better for the 2.0 release. Let's regroup after 1.6 is released, and we can determine timing for approval of this.</p>

  4. Aug 05, 2008

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Comments</ac:parameter><ac:rich-text-body>
    <p>This proposal is approved as-is for standard/library, and will be shipped with 1.6.0.</p>

    <p>At this time, no changes will be made to Zend_View to reflect the new interface and abstract class; in a future revision, we will start introducing features that take advantage of them so that we can begin transitioning to a hard dependency in future releases.</p></ac:rich-text-body></ac:macro>