cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: Woody flow example do not work
Date Thu, 21 Aug 2003 11:45:23 GMT


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 Form.show() 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, Form.show() 
> 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 Form.show() method.
> 
> So we can see that an event handler decides two different things :
> - should the form be validated ?
> - should we exit form.show() ?
> 
> 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" :-)

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

(that and changing the name for sure)

But let me get into this code a bit first to make some more solid 
statements. (it's part of Bruno's stuff I haven't yet really 
delved into)

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

doing the same...

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message