<snip/>
I proposed to introduce a datatype dictionary to factorize common type definition (along with their validators and selection-list). This would turn your example into something like:
<wd:datatype id="email" base="string"> <wd:validation> <wd:email/> </wd:validation> </wd:datatype>
And then: <wd:widget id="supplierEmail" required="true"> <wd:datatype base="email"/> </wd:widget>
hm.. that's what I had in mind when I read Reinhard's proposal
Cool.
Multi page forms ----------------
We have already discussed this several times on the dev-list and at the
GetTogether in Gent. IIUC Thorsten, Bruno and I agreed that we don't
like some kind of a "phases" concept because everything you need can be
found at the template and why should you declare things twice. If you
think of dynamic forms (e.g. wheter a widget is show depends on the
rights of the user) you also come into troubles because your phases will
have to become dynamic too!
As mentioned the list of the required widgets is already known because the template transformer instantiates all widgets. But there is a problem (or at least I'm not sure how to solve it) with this approach: The template transformer is the last step before a new continuation is created.
Nope. The continuation is created in the controller, before the view processing starts.
well, but the stuff *could* still be saved inside the continuation
Sure, but do you mean that the transformer would have a side effect on the form it displays?
<snip/>
What I mentioned was the need for a generic flowscript wizard library,
that could allow to define "backtrack points" in the list of ancestors of the current continuation.
hm... why is backtracking needed? or what do you mean by it?
Well, "backtracking" means "go back to a previous state and restart from there". And this is what continuations allow easily.
I still do see the problem of population if you go back to a previous contiuation. not sure how to use contiuations here properly...
Which "population"? That of the form, or that of the application data? IMO, populating application data should only occur at the end of the wizard. For this, you can either extract the meaningful form information after each screen is displayed, or keep the various forms that compose the wizard and save them all in the application data at the end of the wizard.
The idea is to have a Wizard class that provides two methods:
- markStep(): mark a step in the wizard. A step is a location in the flowscript where we can go back. We may eventually want to name step to allow going back to directly to a step that's not the immediate previous one.
- handleBack(): if the "wizard-back" button was clicked, restore the previous continuation in the step stack.
hm... could elaborate a bit more here?
The wizard keeps a stack of continuations, and a new one is added on markStep(). The handleBack() method checks if a particular button has been clicked (the "back" button in the form) and in that case pops the last continuation and restores it, thus displaying the "previous" screen.
I already did this on a previous project to select people in a corporate directory containing about 6000 entries. The user can type in a few letters, and then the popup automatically displays the names starting with these letters.
cool ...as a new type of widget?
Well, soooo many widgets to write... ;-)
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
