Re: Multipage Forms: Design Question

From: 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 >

« previous php.pear.general (#7360) next »