Zend_Controller_Action_Helper_Multiform Proposal - Simon Mundy

<p>Cheers Keith! Sorted.</p>

<p>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.</p>

<p>Yes there will! I've deliberately held back for two reasons - I wanted to see how MVC would progress before I determined how this component should best fit into an application, and I also wanted to see if we could progress Zend_Form a bit. The latter is still TBC but now I have a better understanding of the former I've been able to build a reasonably sturdy model that utilises the new request object and the Zend_Session component.</p>

<p>Essentially the class skeleton is:-</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
abstract class Zend_Form_Controller extends Zend_Controller_Action
{
const ACTION_PREFIX = '_';

protected $_id = 'default';
protected $_page;

private $_map;
private $_current;
private $_default;

public function __construct(...params...)
final public function indexAction()
abstract function cancelAction();
abstract function submitAction();
abstract function successAction();
abstract function failureAction();
protected function _default($values = array())
protected function _handle($form)
protected function _register($key, $object)
protected function _registry($key)
protected function _export($page = null)
protected function _clear()
protected function _complete()
private function _validate()
private function _isValid($current)
private function _getValid()
private function _checkPage($page)
private function _save($values, $valid = false)
private function _filter($value, $prefix)
]]></ac:plain-text-body></ac:macro>

<p>The '_page' property is an array of valid action names that are required for the form to complete. So I may have something like:-</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
$_page = array('details', 'product', 'card', 'review');
]]></ac:plain-text-body></ac:macro>

<p>Each of these page names are public methods (detailsAction(), productAction() etc...) and need to be validated/completed sequentially in order to complete the form.</p>

<p>There are 4 abstract methods that need to be given concrete methods in the user class - cancel, submit, success and failure. That's because it's easier to allow the developer to implement their own business logic without needing to call parent methods to perform housekeeping on the form. So really the 'cancel', 'success' and 'failure' methods should call '_clear' when they are done (to reset the session) but it's a choice left to the developer.</p>

<p>The '<em>handle' method takes care of validating and processing. An array of user-submitted data (taken from a PEAR form class, for example) is passed acrossed and saved in the $_map property. If a submit value contains a '</em>' prefix it indicates an action is to be taken from the post. So if you had a next button with the form name of '<em>next' it calls the next action, '_back' is back, '_submit' calls the 'submit' action, '_cancel' calls cancel, etc. Or you could jump to a specific action by prefixing the action name with '</em>' (like _product would redirect the user to the 'productAction' page). The prefix is developer-configurable, too.</p>

<p>The default implementation enforces sequential entry but there's no reason why a more flexible approach could be taken (for a user pref form, for example, that's controlled by 'tabs').</p>

<p>Here's a concrete example that extends this class:-</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
<?php

class Payment_MemberController extends Zend_Form_Controller
{
protected $_product;
protected $_page = array('member',
'card',
'review');

protected function init()

public function memberAction()

public function cancelAction()

public function submitAction()

public function successAction()

public function failureAction()

}
]]></ac:plain-text-body></ac:macro>

<p>The code above represents a working solution in a production environment, so I'll post the less-specific abstract class shortly for everyone's review to see if it meets expectations. I'm still on-the-fence as to whether this deserves a whole new component or whether it's simply a new class within the Zend_Controller family... Would appreciate everyone's feedback.</p>

<p>Thanks for the prod Matthew!</p>

<p>Wow, I hadn't realised it had been over a year since I wrote this! Would love to hear how you get on with it - I'm using it in a production site without any troubles at the moment.</p>

<p>I'm not sure what MR's requirement was for duplicate submissions... but if it helps, the component performs a HTTP redirect after each form is submitted so performing a browser refresh will only act on the current page, not attempt to re-submit any POST data.</p>