Re: Woody flow example do not work
On Thu, 2003-08-21 at 14:59, Sylvain Wallez wrote: (on the topic of the validator function in woody flowscript integration) Thinking further, I really think we must separate event handler and application-related-validator. These are really two different concerns. yep, they should be split. 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 -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Woody flow example do not work
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
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 ?
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.
Sylvain
PS: cc'ing directly Marc Steven because of the overflow problems of
Apache's mail server...
--
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
Re: Woody flow example do not work
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 Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
[EMAIL PROTECTED] [EMAIL PROTECTED]
Woody flow example do not work
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. cocoon version: today's CVS LG -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(600)341118 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
Re: Woody flow example do not work
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.
Anyway, the reverting patch is attached if you can't wait.
Cheers,
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org
Index: src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js,v
retrieving revision 1.8
diff -u -r1.8 woody.js
--- src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js 16 Aug
2003 13:22:28 - 1.8
+++ src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js 20 Aug
2003 18:37:12 -
@@ -153,8 +153,8 @@
} else {
this.submitId = undefined;
}
-if (finished validator != undefined) {
-finished = validator(this);
+if (validator != undefined) {
+finished = validator(this) finished;
}
if (finished) {
break;
