cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: CForms Wizards
Date Sun, 14 Nov 2004 18:32:36 GMT
Sylvain Wallez wrote:
> Daniel Fagerstrom wrote:
>> 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.

Before I answer I'd like to point out that the bugzilla entry 
illustrates two different things: flowscript "back-button magic" for 
CForms and "validating what's in the template". Even if they in 
combination IMO is a very promising candidate for having easy to wrte 
multi page wizards in Cocon, they can be evaluated and used separatly.

The flowscript stuff can be used together with widget states and could 
be put into the trunk quite soon. A better metod for communicating 
between the form and the flow script form handling code is needed first. 
And I would also prefer to discuss the code and idea a little bit first 
as it is intricate stuff. I will hopefully find time to write an RT 
about the details soon.

The "validating what's in the template" is IMO promising stuff and is 
part of the CForms refactoring vision, that I talk about all the time ;) 
But it is not ready for prime time yet. It is on going work.

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

Sure, IMO, you should always do a complete validation of _all_ widgets 
before binding your form model to business data. There is the same 
problem with widget states, you can have faulty event logic so that you 
happens to hide some subtree during all states in the filling in of the 
multi form.

So, partial validation is used after each sub form in a wizard to give 
immediate feedback. Then complete validation is done before using the 
data. This is IMO the only safe option.

> Also, this behaviour only validates terminal widgets and no container 
> widgets, which may carry some additional semantic checks like row 
> uniqueness in a repeater.

I'm aware of that as you can see in the bugzilla comment, and have not 
thought that much about of it yet. One possibillity could be to let 
value change "bubble" and let the container validators trigger on child 
events. Any other ideas? I have not used container validators yet, so I 
don't know that much about the use cases.

> So although reading only widgets present in the original template may 
> make sense, using that same widget list for validation is wrong. 

Wrong. based on missing parent validation, or are there further reasons?

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

Wrong and useless, you are using strong words Sylvain ;)

If we can find a good solution of the parent validation problem, it is 
rather usefull as we only need to tell about what widgets that we want 
to validate once, in the view. Furthermore, even if I have no immediate 
need for that, Jonas has shown that it makes it safe to use a form frame 
work without having a form model in between the view and the "business 

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

I implemented it in that way because I didn't had any use cases for 
something more complicated. But you can send a "go back" message 
together with a web continuation id to the form handler, by using that 
the form handler can first save the current form data and then jumping 
to any previous continuation. I'll explain the details in the above 
promised "back-button magic" RT.

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

Either you decide what should be shown together in the view or in the 
model. You get <jx:if> (or separate templates), in the first case and 
fd:structs in the second. IMHO it is better to code view aspects, like 
what should be shown in the same sub view, in the view than in the 
model. It will be easier to reuse the model for several views, e.g. 
specialist view (one screen), wizard view and pda wizard view, if you 
don't put the view groupings in the model.

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

Seem like good ideas.

> 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().

:) So we booth belive that multi chanel wizards mainly should affect the 
view. But you want AFAIU to have event based flow control in the model 
and I prefer to have flowscript based flow control.

We introduced flowscripts in Cocoon once because we thought that it was 
a better way to control flow in e.g. wizards than using FSMs, were we wrong?

A problem with coding where we are in the wizard, booth as a widget 
state and a flowscript state (i.e. where we are in the form handling 
loop), is that previous continuations might get inconsistent. What 
happens if the user happens to use the browser back button in a widget 
state based wizard e.g.


Anyway, thanks for evaluating the proposal and comming with constructive 
critic. I have some interesting new things to consider :)


View raw message