cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: CForms Wizards
Date Sun, 14 Nov 2004 14:19:25 GMT
Daniel Fagerstrom wrote:

> Reinhard Poetz wrote:
>>  --- Sylvain Wallez <> schrieb:
>>> Reinhard Poetz wrote:
>>>> Sylvain Wallez wrote:
>>>>> Sylvain Wallez wrote:
>>>>>> Sorry to rain on the party, but the new widget state stuff in 
>>>>>> CForms should make building multi-page forms a piece of cake.
>>>>>> Off writing an example....
>>>>> Done, I wrote my first wizard with CForms :-)
> <snip/>
>> Thanks for your remarks. If nobody beats my, I'll try
>> to implement the wizard example by following your
>> ideas next week.
>> -- 
>> Reinhard
> Take a look at 
> where I have enhanced work of Jonas Ekstedt so that one can do the 
> kind of things you asked for in the section about multi page forms in 
> So now it is possible to write CForms wizards by writing javascript 
> FSMs in the form definition using widget states. Or if you prefer, by 
> using flowscript back-button magic, and automatic selection of what is 
> validated based on what widgets you use in your template.

There's a problem by validating what's in the template, IMO: this means 
that if the template is wrong, i.e. it misses some important widget 
defined by the form, the form will be incorrectly considered valid. 
Also, this behaviour only validates terminal widgets and no container 
widgets, which may carry some additional semantic checks like row 
uniqueness in a repeater.

So although reading only widgets present in the original template may 
make sense, using that same widget list for validation is wrong. And 
again, registering this list of used widgets will become useless once 
widgets don't reset their values if their corresponding parameter is not 
present. I'm just waiting for the release before adding this new feature.

Furthermore, flowscript back-button magic implies that we can only 
navigate back to the previous screen, and not in an arbitrary screen in 
the sequence.

> But in the later case you miss the joy of writing all the javascript 
> event handling code ;)

Sure, but you still need a lot of <jx:if> in the template, wheareas 
activating/hiding groups means you just declare all groups (fd:struct) 
in the template and it adapts automatically.

And while writing the sample, some new <fd:wizard-action> widgets with 
builtin event handling popped up in my head, just like we have today 
<fd:repeater-action> and <fd:row-action>. No more javascript 
event-handling, no <jx:if>.

One last point also: being able to split a form across multiple page may 
allow for multi-channel forms, where the full form is shown on a regular 
browser, whereas it is split across several pages for PDAs or phones. 
That split can be decided by the view, choosing the appropriate template 
depending on the browser type, with no impact on the flowscript which 
will just have a single form.showForm().


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

View raw message