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 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" :-)


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

--
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com




Reply via email to