Multipage Forms: Design Question
| From: | Marco Schuler | Date: | Fri, 22 Aug 2003 08:56:55 +0000 |
| Subject: | Multipage Forms: Design Question | ||
| Groups: | php.pear.general | ||
| Request: | Send a blank email to pear-general+get-7346@lists.php.net to get a copy of this message | ||
Hi all
Mybe I am OT with my question on this list. If so, please point me to
the rigth list to ask this question.
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:
There are 3 basic classes:
- FormPageManager
- FormPage
- Event
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.)
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.
I would be very glad to hear your comments, suggestion or tips on
developing such a framework.
And once again, please point me to the rigth list if I am OT on
pear-general.
Thanks!
--
Cheers!
Marco