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 12:59:05 GMT
Marc Portier wrote:

> Sylvain Wallez wrote:
>> 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 :-/
> Naah, no need to be so hard on yourself.
> You actually made things better by introducing the use case below:
>> 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 validated.
>> 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 form
>> - 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 results.
>> What do you think ?
> I think "another great analysis by mr Wallez" :-) 

Thanks :-)

>> 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.
> hm, I'm wondering if the logic doesn't just become a lot more easy to 
> read if validator(this) gets to do this decision making internally.  
> Of course it would then need the aditional argument "finished" 
> indicating if you expect it to do validation or not?

Thinking further, I really think we must separate event handler and 
application-related-validator. These are really two different concerns.

Furthermore, the event handler decides if the _form_ validation should 
occur, meaning that if a single function is to implement both concerns, 
the event-handling part has to manually validate the form and check the 
validation result before going to its application-related-validation 
part. This is not clean, and opens the door both to unreadabable code 
and to complicated bugs (what if I do business validation on a form 
which is not valid?).


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

View raw message