cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Thoughts on Woody ...
Date Wed, 22 Oct 2003 09:27:59 GMT
Torsten Curdt wrote:

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


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

>> 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 a new type of widget? 

Well, soooo many widgets to write... ;-)


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message