cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Wizard using CForms doesn't work?
Date Wed, 15 Sep 2004 19:24:30 GMT
Tim Larson wrote:

>On Wed, Sep 15, 2004 at 07:08:20PM +0200, Sylvain Wallez wrote:
>>Stephan Coboos wrote:
>>>I need to implement a wizard using CForms. For this I had created one 
>>>form definition which contains all fields of all wizards. Within the 
>>>flowscript I only create one form instance for all shows. Each wizard 
>>>form will contain a subset of fields of the form definition. At the 
>>>end of the wizard trip I want to get all datas into one model. My 
>>>flowscript looks something like this:
><snip example/>
>>>But this doesn't work. The first wizard will be shown and the second 
>>>one, too. But after filling out and sending the second form cocoon 
>>>will allways display the second wizard and not go to the ok.html 
>>>page.  Isn't it possible to make several calls of showForm on one 
>>>instance? Whats wrong here? Is this a known problem?
>>Yup, this is a know problem if your form contains required fields, as 
>>you won't exit a form.showForm until the form is valid, i.e. all 
>>required fields have a value. And they may not be present on the page 
>>you display...
>The problem is that any widget that is not displayed on the current
>page does not have its request parameter and value submitted on form
>POST, so its value is reset to null.  So when you post one page of
>your form, all the widgets in all the other pages lose their values.

That's an additional problem, but even if this is solved, there's still 
the problem that form.showForm() doesn't exit is some fields are not 
valid (e.g. some who are displayed in a following screen).

>There are several different solutions:
>  * Wrap each page in a struct widget and use the new methods I
>    recently added (e.g. setProcessRequests()) to control which
>    sets of widgets process their request parameters.  You can
>    call these methods from your flowsript or from event handlers.

Can you elaborate on the use case that led you to add these new methods?

>  * Wrap your form in a union widget and put the pages in struct
>    widgets as the cases of the union.  The unions in the model,
>    template, and (if you use one) binding controls which widgets
>    are displayed and which widgets process their request params.

Mmmh... IMO, the union widget should be strict about the selected case, 
and should allow to access widgets other than the selected one.

>  * Split your form into several separate forms, and use your
>    flowscript to go from one to the next.

That seems to me the safer and more "future-proof" way of doing it. 
Also, these separate forms can be bound to the same business object, 
each form dealing with particular parts of that object.

>Btw, anybody have comments about the new methods?
>Are they acceptable to keep, properly implemented, etc.?

Read inline :-)


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message