New Proposal Template This page has been created from a template that uses "zones." To proceed: Edit the page Replace sample content within each zone-data tag Remove this notice Save the page When you are ready for review, remove the Under Construction notice

Under Construction This proposal is under construction and is not ready for review.

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

Zend Framework: Zend_Layout Component Proposal

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

• Harry Houdini Wikipedia Entry
• MagicTricks.com

3. Component Requirements, Constraints, and Acceptance Criteria

• This component will ...

4. Dependencies on Other Framework Components

• Zend_Exception
• Zend_Controller_Action_Helper_ViewRenderer
• Zend_Controller_Plugin_Broker
• Zend_View_Interface

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 (http://www.martinfowler.com/eaaCatalog/twoStepView.html). 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 (named LayoutManager), 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 LayoutManager), 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. In a seperate proposal, there will be View Helpers (view object aware helpers) that can demonstrate this dependency injection.

6. Milestones / Tasks

• Milestone 1: design notes will be published here
• Milestone 2: Working prototype @ http://svn.ralphschindler.com/repo/ZendFramework/Zend_Layout/
• Milestone 3: Working prototype checked into the incubator supporting use cases
• Milestone 4: Unit tests exist, work, and are checked into SVN.
• Milestone 5: Initial documentation exists.

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

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

7. Class Index

• Zend_Layout
• Zend_Layout_ActionHelper_LayoutManager
• Zend_Layout_ControllerPlugin_LayoutProcessor
• Zend_Layout_Request
• Zend_Layout_Exception

8. Use Cases

9. Class Skeletons