Zend_Controller_Action_Helper_Multiform Proposal Review
| Proposal Review Period This proposal is for review until August 18, 2006. This may change as the review progresses and more or less time is needed. You may enter comments directly at the end of the document, or for more directed comments you may create a new issue in the issue tracker for this project. |
Zend Framework: Zend_Controller_Action_Helper_Multiform Component Proposal
| Proposed Component Name | Zend_Controller_Action_Helper_Multiform |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Controller_Action_Helper_Multiform |
| Proposers | Simon Mundy |
| Revision | 0.1 - 9 June 2006: Initial version 0.2 - 1 August 2007: Reworked version using new Helper component architecture (wiki revision: 22) |
Table of Contents
1. Overview
Zend_Controller_Action_Helper_Multiform provides a method for handling modal form submission between controller actions. It allows developers to define a sequence of actions for which forms can be created and validated and have their submitted data stored in a container. Multiform interacts heavily with the Controller, Request object and other Helpers to provide automatic handling of redirects, storage and retrieval.
2. References
3. Component Requirements, Constraints, and Acceptance Criteria
- Ability to create 1 or more form 'pages' from which an end-user can work through either in a linear approach.
- Provide a method for storing data per action.
- Provide a method to pass control back to the parent controller.
- Provide a way of setting global form default values and per-page default values.
- Provide a way of retrieving global form values and per-page submit values.
- Allow methods to clear a multi-page 'session' if a user navigates away from the controller.
- Provide a method to export the current form object as either an array, pure HTML or as a view helper
- Release dependency on a Form object (e.g. HTML_QuickForm) and instead provide a single interface from which to accept forms for population, validation and data retrieval
4. Dependencies on Other Framework Components
- Zend_Exception
5. Theory of Operation
A Multiform instance is referenced from each action within a controller. Ideally, the developer will retrieve an instance from the Helper Broker in the preDispatch phase of the controller and pass a sequence of actions for it to follow, as well as setting default values.
Each Action within a Multiform can be queried to see if it been submitted, whether it is valid and to return any submitted values if applicable. The processing of each Action happens simply by calling the 'update' method with an array of form data and a flag to indicate whether the form data has been validated. The validation flag is necessary, as sometimes the developer may wish to store form values even though the end user wants to go 'back' or 'jump' to a specific page.
Navigation from one Action to the next is achieved by passing control values inside the form data (e.g. a submit button with a specific name). The defaults are for an underscored control key - _next, _back, _submit, _cancel - however these can be changed by the developer to any scheme they desire.
To ensure data is stored between actions all controller-submitted data will be stored in a namespaced session. An existing Zend_Session can be passed to the Controller for convenience, otherwise a default instance is used. The session data remains active until a developer explicitly clears it or the session expires.
6. Milestones / Tasks
7. Class Index
- Zend_Controller_Action_Helper_Multiform
- Zend_Controller_Action_Helper_Multiform_Exception
8. Use Cases
| UC-01 |
|---|
In this example, we require 3 forms for a user to fill out - a Personal details form, a Product order/payment details form and a Review page to confirm approval. The 3 forms themselves are an exercise for the developer to complete - what we are interested in is getting the data from those forms and storing them.
The first form has two 'submit' buttons named '_next' and '_cancel' - the former allowing access to the next page when the form is submitted and valid, the latter allowing a user to cleanly cancel the session.
The second form has '_next' and '_back' named submit buttons to navigate forward and backward, allowing revision of the form if desired.
The third form has '_submit' and '_back' named submit buttons. The 'submitAction' controller action will be called only if all three forms have been submitted and validated.
Note also that a user cannot manually navigate to any action without previous actions having been successfully navigated. If, for example, the user navigated to '/payment/review' without having submitted their details or product, Multiform will perform a redirection back through the sequence to determine the correct action to begin with.
9. Class Skeletons
I'm a little confused by this proposal. Is this a Form Controller or an Application Controller. It seems to be a little of both.
It's intended to pass the processing of multiple pages (and validation, etc) to the helper class Zend_Form_Controller so that the parent controller needs only act upon a form submission once an entire form has been processed. So IMO it falls into the former definition.
So is Zend_Form_Controller an Application Controller and the rest a Form Controller?
Sorry, I think I see the meaning of your first question now. Each 'page' is a form controller allowing validation, filtering and processing. The parent class - Zend_Form_Controller - is an application controller soley for those pages, but doesn't provide any routing. It still allows it's parent controller to provide the routing and/or final processing.
Sounds very good to my, although I am not quite sure if I fully understand your proposal. Where will the form building and rendering be handled?
In your UC-01 you have an example for extending Zend_Form_Controller_Page which uses a Form class.
Do I get it right, that this proposal does not include the form building part, i.e. generate the HTML for <input> and <select> fields? If so, we could still need a Zend_Form component, couldn't we?
Thanks for your work so far. ![]()
Indeed - as there is currently no working component for Zend_Form, I've left the actual implementation of form building to the end-user. Hopefully this can be remedied soon with a new Zend_Form proposal...
So for the moment you would create your own form object and pass it to the controller
$controller->setForm($yourFormObject);
...and then when you're ready to display, you simply call render
$view->form = $controller->render();
This would return data according to the specs of your form object (associative array, object, fully-formed HTML string, etc).
ZF Home Page
Code Browser
Wiki Dashboard
Looks great
I think you have a small typo in your use case section.
the second class - MyApp_Form_Page1 extends Zend_Form_Controller_Page
Should be class MyApp_Form_Page2 extends Zend_Form_Controller_Page