Re: Multipage Forms: Design Question
| From: | Laurent Laville | Date: | Fri, 22 Aug 2003 17:17:12 +0000 |
| Subject: | Re: Multipage Forms: Design Question | ||
| References: | 1 | Groups: | php.pear.general |
| Request: | Send a blank email to pear-general+get-7360@lists.php.net to get a copy of this message | ||
Hi all,
I've already worked on a wizard-style panels (back, next buttons) which will
use HTML_Quickform
OK i know that goals of my HTML_SetupWizard is not what you are waiting for,
but coding / implementation
could you give some ideas and solutions.
There are not yet a public release, but all sources and package are
available at :
http://farell.free.fr/en/pear/sources/HTML_SetupWizard/
Latest version is 1.0RC2
I'll keep working on it, after i've finish and release a next release 0.6.0
for HTML_Progress (my other package)
If you need more information, contact me !
Laurent
PS: i know that i've still to work on a good SW doc, as i did with
ProgressBar.
"Marco Schuler" <marco.schuler@scopein.ch> a écrit dans le message de news:
1061542615.2038.45.camel@opal...
> 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
>