cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
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

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message