You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Leszek Gawron <ou...@wlkp.org> on 2003/08/20 11:57:42 UTC
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 // \\
\_\\ //_/ ouzo@vip.net.pl _\\()//_
.'/()\'. Phone: +48(600)341118 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
Re: Woody flow example do not work
Posted by Marc Portier <mp...@outerthought.org>.
Marc Portier wrote:
<snip />
>> 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)
>
never mind my half baked proposal and rumbling,
I just got into this deeper and saw your fresh committed fix.
nicely solved!
-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
Re: Woody flow example do not work
Posted by Bruno Dumon <br...@outerthought.org>.
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
bruno@outerthought.org bruno@apache.org
Re: Woody flow example do not work
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
Re: Woody flow example do not work
Posted by Marc Portier <mp...@outerthought.org>.
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
Re: Woody flow example do not work
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Sylvain Wallez wrote:
<snip/>
> 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.
Fixed. Tested both the examples and my application which justified the
intial change. Here's the updated snippet that is now in CVS :
// If either validation was successfull or there was an event,
call the validator
if ((finished ||this.submitId != null) && validator != undefined) {
finished = validator(this);
}
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
Re: Woody flow example do not work
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
Posted by Steven Noels <st...@outerthought.org>.
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 Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org