Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History


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

Zend Framework: Zend_Layout Component Proposal

Proposed Component Name Zend_Layout
Developer Notes
Proposers Ralph Schindler
Matthew Weier O'Phinney
Revision 1.0 - 5 July 2007: Updated from community comments.
1.1 - 10 Aug 2007: Took out of construction and placed under review
1.2 - 30 Aug 2007: Updated proposal with new class skeletons (wiki revision: 5)

Table of Contents

1. Overview

Zend_Layout is a composite component that joins the Controller, View and ViewRenderer together to implement a two-step-view pattern for solving the problem of "consistent look and feel".

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • Must work with a dispatch loop and named response segments. Since we can forward between actions, or create a loop of actions to dispatch, and because the response content can exist in multiple segments, we have special needs and capabilities other frameworks don't. Rendering must be done after the dispatch loop has finished, and should use all content segments.
  • Must be able to work without MVC. While the above should be true, Layouts should be available to those not wanting to use the MVC, or using an alternate MVC.
  • Must be simple to invoke. A controller should be able to specify a layout at will, and this should be easy to do.
  • Must be configurable
    • Must be able to specify which layout to use, but allow for a 'default' layout
    • Must be able to specify location of layouts
    • Must be able to specify names of layout variables
  • Must be able to pick and choose which placeholders to render
  • Must have a simple API for specifying items to use in the <head> section In discussion with Ralph, we've decided that view variables and the collection helper are the proper solution for this.
  • Must follow same naming conventions followed in ViewRenderer
    • naming
    • suffixes
  • Must inherit from view set in view renderer (if in use). This allows view scripts as well as action controllers to set variables to use in the layout.

4. Dependencies on Other Framework Components

  • Zend_Exception
  • Zend_View_Interface
  • Zend_View_Helper_Placeholder (potentially; for variable storage and retrieval)
  • Zend_Controller_Action_Helper_ViewRenderer (will likely push inflection into a new class, and ViewRenderer and Zend_Layout will utilize that)
  • Zend_Controller_Plugin_Broker (optional)
  • Zend_Controller_Action_Helper_Abstract (optional)
  • Zend_Controller_Action_Helper_ViewRenderer (optional; for shared view object)
  • Zend_Controller_Action_HelperBroker (optional)

5. Theory of Operation

Zend_Layout attempts to solve a problem that, since rearing its ugly head over and over, has gone by many names: Composite Views, Layouts, Templates, Partial Views, and/or Complex Views. They all basically attempt to describe a common problem - that of being able to maintain a consistent look and feel throughout a site or web application while maintaining the "Don't Repeat Yourself" principals.

Zend_Layout addresses the problem with a common pattern, the two-step-view pattern ( The Two Step View pattern breaks the process up into two distinct stages. The primary stage allows the user requested action as well as layout requested actions to dispatch and execute their respective views saving them to the controllers response object. The second stage of the process takes the already dispatched actions responses and directs them to the layout where final placement of content is made (in a Layout specific view) before being sent back to the user.

Zend_Layout requires no changes to the existing codebase to accomplish its job. To maintain control over the dispatch process, Zend_Layout attaches a controller plugin - this is the essense of the Two-Step-View and a common way to implement the 2SV as we have seen already. Zend_Layout also registers its own action helper, so that the developer can directly interact with Zend_Layout from within their actions. Depending on the state of the layout subsystem (defined by either the config file, bootstrap declarations, or interactions with the action helper), Zend_Layout will engage and act as directed by the developer by either dispatching a 2SV layout, or simply not engaging at all (if so desired).

A major benefit the Two-Step-View implementation is that user requested (and layout requested) action controllers and views can inject dependencies into the final layout. For example, if the user has requested a url that would generate a form, the form view can request that the section of the overall layout include a specific form.js file, or even a form.css file be linked in the head section.

Finally, Zend_Layout can be used with the MVC, if so desired. If used in this way, it simply acts as a wrapper on Zend_View, allowing the developer to inject layout-specific variables.

6. Milestones / Tasks

If a milestone is already done, begin the description with "[DONE]", like this:

  • Milestone #: [DONE] Unit tests ...

7. Class Index

  • Zend_Layout
  • Zend_Layout_Action_Helper_Layout
  • Zend_Layout_Controller_Plugin
  • Zend_Layout_Exception
  • Zend_View_Helper_Layout
  • Zend_View_Inflection (Used by both ViewRenderer and Zend_Layout for mapping script names to actual scripts)

8. Use Cases



Action controller accessing layout

View accessing layout

9. Class Skeletons







Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.