Re: Multipage Forms: Design Question

Hi! Marco Schuler wrote:

I am working on a framework for easyly creating multipage forms (wizard-like) using HTML_QuickForm. I got a basic concept for it and I wanted to ask if there are better ideas around to do it. Let me explain my approach:

Wow! The idea seems really floating around. We (Bertrand Mansion and myself) are developing a package under a working title HTML_QuickForm_Controller which will do exactly this. Here is a working demo of a wizard-like form: http://158.250.10.119/qf/example-Wizard.php No publicly available code yet, sorry.

There are 3 basic classes: - FormPageManager - FormPage - Event

Yes, but called Controller, Page and Action. :]

FormPageManager: This abstract class is intended to handle the paging of the whole wizard. The structure of the wizard should somehow be known by an extended class derived from the FormPageManager-class. It's task are: - has knowledge about first/last/next/previous pages to display, depending on events triggered by a specific FormPage - hadles events triggered by a FormPage - calls current FormPage methods to display, evaluate and process its form input - uses sessions or object-serialization to remember current page FormPage: This abstract class is intended to represent a specific FormPage in an extendend class. Tasks of this class are: - can validate its form input - can process its form input (maybe by using DB_DataObject) - can display itself - trigers events like prev/next button pressed etc. by triggering events using an event object as return value. Event: This class should manage the "transport" of event-messages from a FormPage-subclass to a FormPageManager-subclass. Its task are: - lets trigger an event providing eventname and a possible action to take. These events will be used by the FormPageManager to take appropriated actions (prev/next etc.)

OK, we took a slightly different approach, quoting: ========== Classes: 1) Controller class * Contains Page objects * Can contain (kind of default) Action objects * Checks the request and calls the necessary handler * Manages storing data in sessions 2) Page class (a child of HTML_QuickForm) * Has methods for on-demand building of the form and building of filtering/validation stuff * Can contain Action objects that define form handling * If the page has an Action object registered for a specific action, it is used. Else the Controller's default Action object is used. 3) Action class * Implements the Command design pattern (in other words: it is an OO callback) * We will provide some basic Actions, but mostly people will do their own ========== All the business logic is contained in Action objects. Controller doesn't need to be subclassed, Page can be subclassed, but you only have to provide a buildForm() method which will call addElement() and addRule(). Alternatively you can build a form yourself. Actions have to be subclassed, but some common actions ('back', 'next', 'go') will be provided. Of course you will need your actions to display the form (unless you are happy with a default layout) and to process it.

As you can see, there are abstract classes (methodes respectively) that will have to be overwritten by the user of the multipage form framework. I am not shure if this is the PEAR-like approach. Mybe there should be some advanced configuration facility for the whole framework in a way that there is no need for subclassing over and over for every wizard and every wizard page. Furthermore I am not sure if using an event-object is a good solution.

The advanced config solution will be easily pluggable.

I would be very glad to hear your comments, suggestion or tips on developing such a framework.

Well, as we managed to independently invent roughly the same structure, that probably means the ideas are good enough. :]

And once again, please point me to the rigth list if I am OT on pear-general.

Well, maybe pear-dev will be a more appropriate one.