cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Woody flow example do not work
Date Thu, 21 Aug 2003 08:47:03 GMT
Steven Noels wrote:

> Leszek Gawron wrote:
>> I do not think it's a thing to be put into bugzilla so it goes here: 
>> while the "standard" woody form example is fully functional the flow 
>> version
>> does not allow you to add or remove a contact.
> We've debugged this offline already (Marc and myself during a car ride 
> this afternoon), and changing line 156-157 into:
>         if (validator != undefined) {
>             finished = validator(this) && finished;
> will solve this as far as we can see now. But since Sylvain was quite 
> specific about this in his commit changing the original version some 
> days ago, we've not patched this before getting the word out to him. 

Doh ! I'm the culprit :-/

I changed this since I considered that flow-level validation (this is 
the use implied by it's "validator" name) should occur only when the 
form was successfully validated.

But looking further at the samples, I see that this "validator" function 
is also the event handler that reacts to <wd:button> widgets, and in 
that case Form.process() returns false, because the form has not been 

I think the behaviour of in JavaScript should mimic the one 
or Form.process() in Java : if there's an actionCommand, call the 
handler, and then ask the FormContext to know if validation should be 
performed or not. This allows actionCommand to do their job, and 
optionally decide if validation should occur. For this, 
needs two parameters : the event handler function and the validator 
function. Each of these functions should return a boolean that decides 
what to do next.

But things can be even more complicated, and AFAICS cannot be handled by 
the current implementation of form processing, because the event handler 
*has* to decide if validation should be performed or not. Imagine for 
example a purchase order form that provides 3 buttons : the normal 
button which sends the order, a "save as draft" button that saves the 
order but does not send it and a "add item" button. The first two 
buttons should validate the form and exit the show() function. The third 
one should not validate the form and redisplay it.

Here are the behaviour of these 3 buttons :
- normal submit : no event handler, validate and redisplay the form if 
validation failed
- add item : call event handler, don't validate and always redisplay the 
- save as draft : call event handler, validate and redisplay the form if 
validation failed
- cancel : call event handler, don't validate and don't redisplay the form.

The "redisplay the form" above means that we actually don't exit from 
the method.

So we can see that an event handler decides two different things :
- should the form be validated ?
- should we exit ?

To implement this, the event handler should either change the state of 
the FormContext object or return a value combining these two different 

What do you think ?

As an interim fix, I propose to call the validator function either when 
process() returns true *or* actionCommand != null. It's then the 
validator function's responsibility to know if it's called because of 
successful validation or because of an actionCommand.

PS: cc'ing directly Marc & Steven because of the overflow problems of 
Apache's mail server...

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

View raw message