You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Sebastian Hennebrueder <us...@laliluna.de> on 2009/09/01 21:39:58 UTC
Re: ValidateForm Event
Hello,
the intended validation method for cross field validation is
onValidateForm
The onSuccess is probable the latest point to do validation. I would
only place business logic related validation in there
You may do field validation in the onValidateForm as well but it is
normally simpler, faster and cleaner to do this using annotations.
If you want to do field validation in the onValidateForm I would not
follow the approach of newtonic and write if then statements
but to create a simple builder (see Effective Java).
Sample without reflection inside of the builder
Validator userVal =
ValidatorBuilder.required().minLenth(3).maxLength(60).build();
usage in onValidateForm
userVal.validate(user.getName);
You could leverage this using reflection
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
Benny Law schrieb:
> Hi Onno,
>
> I am all for clean and maintainable code, and that's why I think
> ValidateForm can be cleaner if I didn't need to check for field errors
> first.
>
> On the main Tapestry 5.1 page, the Login example calls the authenticator in
> onValidateForm, but the same example in the User Guide under Input
> Validation does that in onSuccess. I think the latter is correct; the former
> won't work properly because it acts on the properties bound to the fields
> which may not reflect the current field contents if there are field
> validation errors. To fix the first example, some code needs to be added to
> onValidateForm to check if the fields have passed field-level validations
> before invoking the authenticator.
>
> I hope this clarifies what I am thinking. Thanks.
>
> Benny
>
> On Mon, Aug 31, 2009 at 4:57 AM, Onno Scheffers <on...@piraya.nl> wrote:
>
>>> Thanks for your response. Could you explain what you mean by keeping my
>>> validation "in the correct callback"?
>>
>>
>> I think it's about writing clean and maintainable code.
>> For other developers reading back your code it makes more sense if you add
>> your validation errors in the ValidateForm event and to perform some
>> (database?) action in the success handler.
>>
>> The ValidateForm event is where validation errors are added and some of
>> them
>> are automatically taken care of for you by the Tapestry validator
>> mechanism.
>> If you don't want to add more than one error-message, you can easily check
>> if the field is in error already.
>> Sometimes it also makes sense to add mutiple errors per field since you're
>> telling the user immediately what (s)he's doing wrong instead of having
>> them
>> re-submit again only to find yet another validation error on the same
>> field.
>>
>>
>> regards,
>>
>> Onno
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: ValidateForm Event
Posted by Benny Law <be...@gmail.com>.
That looks very reasonable. I think I will adopt this approach. Thanks
Geoff.
Benny
On Wed, Sep 2, 2009 at 1:02 AM, Geoff Callender <
geoff.callender.jumpstart@gmail.com> wrote:
> Yes, let's hope the doco is updated soon!
>
> https://issues.apache.org/jira/browse/TAP5-812
>
> As for your conundrum, is there a reason you're not happy to do the
> following? It's only a few lines and its intention seems very clear.
>
> @Component(id = "searchForm")
> private Form _form;
>
> void onValidateForm() {
> if (_form.getHasErrors()) {
> return;
> }
> ...
>
> Geoff
> http://jumpstart.doublenegative.com.au:8080/jumpstart/
>
>
> On 02/09/2009, at 12:20 PM, Benny Law wrote:
>
> Thanks for alerting me, Geoff. But even the input validation example in
>> the
>> User Guide shows recording error in onSuccess()! I must say I'm a bit
>> alarmed by these "quirks". I hope I don't find too many more surprises
>> when
>> I get deeper into Tapestry 5.1. I am working on a critical application
>> under
>> a tight deadline, and I am counting on Tapestry to help me deliver. I used
>> Tapestry 3 before and loved it, but 5 is a totally new framework.
>>
>> Benny
>>
>> On Tue, Sep 1, 2009 at 9:46 PM, Geoff Callender <
>> geoff.callender.jumpstart@gmail.com> wrote:
>>
>> Beware, there's a long-standing problem with recording errors in
>>> onSuccess().
>>>
>>> https://issues.apache.org/jira/browse/TAPESTRY-1972
>>>
>>> Geoff
>>>
>>>
>>> On 02/09/2009, at 7:59 AM, Benny Law wrote:
>>>
>>> Thanks Sebastian. I agree that only business logic related validation
>>>
>>>> should
>>>> go into onSuccess, and I would leave basic field validations to
>>>> validators
>>>> as much as possible. My problem with onValidateForm is still the amount
>>>> of
>>>> code I need to write to check for existing errors before I can do cross
>>>> field validation. Let me give a quick example:
>>>>
>>>> Suppose I have two date fields, Start Date and End Date. I would use the
>>>> built-in validators to check for missing values and invalid dates.
>>>> However,
>>>> in order to cross-validate these dates (to ensure Start Date is not
>>>> later
>>>> than End Date) in onValidateForm, I would need to inject the two fields,
>>>> get
>>>> the tracker from the form, and call inError() to find out if any of the
>>>> dates are invalid (missing or bad syntax). If there are no errors, then
>>>> I
>>>> can compare the date properties bound to the fields. Do you see what I
>>>> am
>>>> getting at?
>>>>
>>>> Doing this in onSuccess is a lot easier since I won't need to check for
>>>> existing errors, and I know that the date properties bound to the fields
>>>> have been updated. Ideally, I would love to have another version of
>>>> ValidateForm event which is fired before Success and only if there are
>>>> no
>>>> errors.
>>>>
>>>> Benny
>>>>
>>>> On Tue, Sep 1, 2009 at 3:39 PM, Sebastian Hennebrueder
>>>> <us...@laliluna.de>wrote:
>>>>
>>>> Hello,
>>>>
>>>>>
>>>>> the intended validation method for cross field validation is
>>>>> onValidateForm
>>>>> The onSuccess is probable the latest point to do validation. I would
>>>>> only
>>>>> place business logic related validation in there
>>>>>
>>>>> You may do field validation in the onValidateForm as well but it is
>>>>> normally simpler, faster and cleaner to do this using annotations.
>>>>>
>>>>> If you want to do field validation in the onValidateForm I would not
>>>>> follow
>>>>> the approach of newtonic and write if then statements
>>>>> but to create a simple builder (see Effective Java).
>>>>> Sample without reflection inside of the builder
>>>>> Validator userVal =
>>>>> ValidatorBuilder.required().minLenth(3).maxLength(60).build();
>>>>>
>>>>> usage in onValidateForm
>>>>> userVal.validate(user.getName);
>>>>>
>>>>> You could leverage this using reflection
>>>>>
>>>>>
>>>>> --
>>>>> Best Regards / Viele Grüße
>>>>>
>>>>> Sebastian Hennebrueder
>>>>> -----
>>>>> Software Developer and Trainer for Hibernate / Java Persistence
>>>>> http://www.laliluna.de
>>>>>
>>>>> Benny Law schrieb:
>>>>>
>>>>> Hi Onno,
>>>>>
>>>>>
>>>>>> I am all for clean and maintainable code, and that's why I think
>>>>>> ValidateForm can be cleaner if I didn't need to check for field errors
>>>>>> first.
>>>>>>
>>>>>> On the main Tapestry 5.1 page, the Login example calls the
>>>>>> authenticator
>>>>>> in
>>>>>> onValidateForm, but the same example in the User Guide under Input
>>>>>> Validation does that in onSuccess. I think the latter is correct; the
>>>>>> former
>>>>>> won't work properly because it acts on the properties bound to the
>>>>>> fields
>>>>>> which may not reflect the current field contents if there are field
>>>>>> validation errors. To fix the first example, some code needs to be
>>>>>> added
>>>>>> to
>>>>>> onValidateForm to check if the fields have passed field-level
>>>>>> validations
>>>>>> before invoking the authenticator.
>>>>>>
>>>>>> I hope this clarifies what I am thinking. Thanks.
>>>>>>
>>>>>> Benny
>>>>>>
>>>>>> On Mon, Aug 31, 2009 at 4:57 AM, Onno Scheffers <on...@piraya.nl>
>>>>>> wrote:
>>>>>>
>>>>>> Thanks for your response. Could you explain what you mean by keeping
>>>>>> my
>>>>>>
>>>>>> validation "in the correct callback"?
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> I think it's about writing clean and maintainable code.
>>>>>>> For other developers reading back your code it makes more sense if
>>>>>>> you
>>>>>>> add
>>>>>>> your validation errors in the ValidateForm event and to perform some
>>>>>>> (database?) action in the success handler.
>>>>>>>
>>>>>>> The ValidateForm event is where validation errors are added and some
>>>>>>> of
>>>>>>> them
>>>>>>> are automatically taken care of for you by the Tapestry validator
>>>>>>> mechanism.
>>>>>>> If you don't want to add more than one error-message, you can easily
>>>>>>> check
>>>>>>> if the field is in error already.
>>>>>>> Sometimes it also makes sense to add mutiple errors per field since
>>>>>>> you're
>>>>>>> telling the user immediately what (s)he's doing wrong instead of
>>>>>>> having
>>>>>>> them
>>>>>>> re-submit again only to find yet another validation error on the same
>>>>>>> field.
>>>>>>>
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Onno
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
Re: ValidateForm Event
Posted by Geoff Callender <ge...@gmail.com>.
Yes, let's hope the doco is updated soon!
https://issues.apache.org/jira/browse/TAP5-812
As for your conundrum, is there a reason you're not happy to do the
following? It's only a few lines and its intention seems very clear.
@Component(id = "searchForm")
private Form _form;
void onValidateForm() {
if (_form.getHasErrors()) {
return;
}
...
Geoff
http://jumpstart.doublenegative.com.au:8080/jumpstart/
On 02/09/2009, at 12:20 PM, Benny Law wrote:
> Thanks for alerting me, Geoff. But even the input validation example
> in the
> User Guide shows recording error in onSuccess()! I must say I'm a bit
> alarmed by these "quirks". I hope I don't find too many more
> surprises when
> I get deeper into Tapestry 5.1. I am working on a critical
> application under
> a tight deadline, and I am counting on Tapestry to help me deliver.
> I used
> Tapestry 3 before and loved it, but 5 is a totally new framework.
>
> Benny
>
> On Tue, Sep 1, 2009 at 9:46 PM, Geoff Callender <
> geoff.callender.jumpstart@gmail.com> wrote:
>
>> Beware, there's a long-standing problem with recording errors in
>> onSuccess().
>>
>> https://issues.apache.org/jira/browse/TAPESTRY-1972
>>
>> Geoff
>>
>>
>> On 02/09/2009, at 7:59 AM, Benny Law wrote:
>>
>> Thanks Sebastian. I agree that only business logic related validation
>>> should
>>> go into onSuccess, and I would leave basic field validations to
>>> validators
>>> as much as possible. My problem with onValidateForm is still the
>>> amount of
>>> code I need to write to check for existing errors before I can do
>>> cross
>>> field validation. Let me give a quick example:
>>>
>>> Suppose I have two date fields, Start Date and End Date. I would
>>> use the
>>> built-in validators to check for missing values and invalid dates.
>>> However,
>>> in order to cross-validate these dates (to ensure Start Date is
>>> not later
>>> than End Date) in onValidateForm, I would need to inject the two
>>> fields,
>>> get
>>> the tracker from the form, and call inError() to find out if any
>>> of the
>>> dates are invalid (missing or bad syntax). If there are no errors,
>>> then I
>>> can compare the date properties bound to the fields. Do you see
>>> what I am
>>> getting at?
>>>
>>> Doing this in onSuccess is a lot easier since I won't need to
>>> check for
>>> existing errors, and I know that the date properties bound to the
>>> fields
>>> have been updated. Ideally, I would love to have another version of
>>> ValidateForm event which is fired before Success and only if there
>>> are no
>>> errors.
>>>
>>> Benny
>>>
>>> On Tue, Sep 1, 2009 at 3:39 PM, Sebastian Hennebrueder
>>> <us...@laliluna.de>wrote:
>>>
>>> Hello,
>>>>
>>>> the intended validation method for cross field validation is
>>>> onValidateForm
>>>> The onSuccess is probable the latest point to do validation. I
>>>> would only
>>>> place business logic related validation in there
>>>>
>>>> You may do field validation in the onValidateForm as well but it is
>>>> normally simpler, faster and cleaner to do this using annotations.
>>>>
>>>> If you want to do field validation in the onValidateForm I would
>>>> not
>>>> follow
>>>> the approach of newtonic and write if then statements
>>>> but to create a simple builder (see Effective Java).
>>>> Sample without reflection inside of the builder
>>>> Validator userVal =
>>>> ValidatorBuilder.required().minLenth(3).maxLength(60).build();
>>>>
>>>> usage in onValidateForm
>>>> userVal.validate(user.getName);
>>>>
>>>> You could leverage this using reflection
>>>>
>>>>
>>>> --
>>>> Best Regards / Viele Grüße
>>>>
>>>> Sebastian Hennebrueder
>>>> -----
>>>> Software Developer and Trainer for Hibernate / Java Persistence
>>>> http://www.laliluna.de
>>>>
>>>> Benny Law schrieb:
>>>>
>>>> Hi Onno,
>>>>
>>>>>
>>>>> I am all for clean and maintainable code, and that's why I think
>>>>> ValidateForm can be cleaner if I didn't need to check for field
>>>>> errors
>>>>> first.
>>>>>
>>>>> On the main Tapestry 5.1 page, the Login example calls the
>>>>> authenticator
>>>>> in
>>>>> onValidateForm, but the same example in the User Guide under Input
>>>>> Validation does that in onSuccess. I think the latter is
>>>>> correct; the
>>>>> former
>>>>> won't work properly because it acts on the properties bound to the
>>>>> fields
>>>>> which may not reflect the current field contents if there are
>>>>> field
>>>>> validation errors. To fix the first example, some code needs to
>>>>> be added
>>>>> to
>>>>> onValidateForm to check if the fields have passed field-level
>>>>> validations
>>>>> before invoking the authenticator.
>>>>>
>>>>> I hope this clarifies what I am thinking. Thanks.
>>>>>
>>>>> Benny
>>>>>
>>>>> On Mon, Aug 31, 2009 at 4:57 AM, Onno Scheffers <on...@piraya.nl>
>>>>> wrote:
>>>>>
>>>>> Thanks for your response. Could you explain what you mean by
>>>>> keeping my
>>>>>
>>>>>> validation "in the correct callback"?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I think it's about writing clean and maintainable code.
>>>>>> For other developers reading back your code it makes more sense
>>>>>> if you
>>>>>> add
>>>>>> your validation errors in the ValidateForm event and to perform
>>>>>> some
>>>>>> (database?) action in the success handler.
>>>>>>
>>>>>> The ValidateForm event is where validation errors are added and
>>>>>> some of
>>>>>> them
>>>>>> are automatically taken care of for you by the Tapestry validator
>>>>>> mechanism.
>>>>>> If you don't want to add more than one error-message, you can
>>>>>> easily
>>>>>> check
>>>>>> if the field is in error already.
>>>>>> Sometimes it also makes sense to add mutiple errors per field
>>>>>> since
>>>>>> you're
>>>>>> telling the user immediately what (s)he's doing wrong instead
>>>>>> of having
>>>>>> them
>>>>>> re-submit again only to find yet another validation error on
>>>>>> the same
>>>>>> field.
>>>>>>
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Onno
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>
Re: ValidateForm Event
Posted by Benny Law <be...@gmail.com>.
Thanks for alerting me, Geoff. But even the input validation example in the
User Guide shows recording error in onSuccess()! I must say I'm a bit
alarmed by these "quirks". I hope I don't find too many more surprises when
I get deeper into Tapestry 5.1. I am working on a critical application under
a tight deadline, and I am counting on Tapestry to help me deliver. I used
Tapestry 3 before and loved it, but 5 is a totally new framework.
Benny
On Tue, Sep 1, 2009 at 9:46 PM, Geoff Callender <
geoff.callender.jumpstart@gmail.com> wrote:
> Beware, there's a long-standing problem with recording errors in
> onSuccess().
>
> https://issues.apache.org/jira/browse/TAPESTRY-1972
>
> Geoff
>
>
> On 02/09/2009, at 7:59 AM, Benny Law wrote:
>
> Thanks Sebastian. I agree that only business logic related validation
>> should
>> go into onSuccess, and I would leave basic field validations to validators
>> as much as possible. My problem with onValidateForm is still the amount of
>> code I need to write to check for existing errors before I can do cross
>> field validation. Let me give a quick example:
>>
>> Suppose I have two date fields, Start Date and End Date. I would use the
>> built-in validators to check for missing values and invalid dates.
>> However,
>> in order to cross-validate these dates (to ensure Start Date is not later
>> than End Date) in onValidateForm, I would need to inject the two fields,
>> get
>> the tracker from the form, and call inError() to find out if any of the
>> dates are invalid (missing or bad syntax). If there are no errors, then I
>> can compare the date properties bound to the fields. Do you see what I am
>> getting at?
>>
>> Doing this in onSuccess is a lot easier since I won't need to check for
>> existing errors, and I know that the date properties bound to the fields
>> have been updated. Ideally, I would love to have another version of
>> ValidateForm event which is fired before Success and only if there are no
>> errors.
>>
>> Benny
>>
>> On Tue, Sep 1, 2009 at 3:39 PM, Sebastian Hennebrueder
>> <us...@laliluna.de>wrote:
>>
>> Hello,
>>>
>>> the intended validation method for cross field validation is
>>> onValidateForm
>>> The onSuccess is probable the latest point to do validation. I would only
>>> place business logic related validation in there
>>>
>>> You may do field validation in the onValidateForm as well but it is
>>> normally simpler, faster and cleaner to do this using annotations.
>>>
>>> If you want to do field validation in the onValidateForm I would not
>>> follow
>>> the approach of newtonic and write if then statements
>>> but to create a simple builder (see Effective Java).
>>> Sample without reflection inside of the builder
>>> Validator userVal =
>>> ValidatorBuilder.required().minLenth(3).maxLength(60).build();
>>>
>>> usage in onValidateForm
>>> userVal.validate(user.getName);
>>>
>>> You could leverage this using reflection
>>>
>>>
>>> --
>>> Best Regards / Viele Grüße
>>>
>>> Sebastian Hennebrueder
>>> -----
>>> Software Developer and Trainer for Hibernate / Java Persistence
>>> http://www.laliluna.de
>>>
>>> Benny Law schrieb:
>>>
>>> Hi Onno,
>>>
>>>>
>>>> I am all for clean and maintainable code, and that's why I think
>>>> ValidateForm can be cleaner if I didn't need to check for field errors
>>>> first.
>>>>
>>>> On the main Tapestry 5.1 page, the Login example calls the authenticator
>>>> in
>>>> onValidateForm, but the same example in the User Guide under Input
>>>> Validation does that in onSuccess. I think the latter is correct; the
>>>> former
>>>> won't work properly because it acts on the properties bound to the
>>>> fields
>>>> which may not reflect the current field contents if there are field
>>>> validation errors. To fix the first example, some code needs to be added
>>>> to
>>>> onValidateForm to check if the fields have passed field-level
>>>> validations
>>>> before invoking the authenticator.
>>>>
>>>> I hope this clarifies what I am thinking. Thanks.
>>>>
>>>> Benny
>>>>
>>>> On Mon, Aug 31, 2009 at 4:57 AM, Onno Scheffers <on...@piraya.nl> wrote:
>>>>
>>>> Thanks for your response. Could you explain what you mean by keeping my
>>>>
>>>>> validation "in the correct callback"?
>>>>>>
>>>>>>
>>>>>
>>>>> I think it's about writing clean and maintainable code.
>>>>> For other developers reading back your code it makes more sense if you
>>>>> add
>>>>> your validation errors in the ValidateForm event and to perform some
>>>>> (database?) action in the success handler.
>>>>>
>>>>> The ValidateForm event is where validation errors are added and some of
>>>>> them
>>>>> are automatically taken care of for you by the Tapestry validator
>>>>> mechanism.
>>>>> If you don't want to add more than one error-message, you can easily
>>>>> check
>>>>> if the field is in error already.
>>>>> Sometimes it also makes sense to add mutiple errors per field since
>>>>> you're
>>>>> telling the user immediately what (s)he's doing wrong instead of having
>>>>> them
>>>>> re-submit again only to find yet another validation error on the same
>>>>> field.
>>>>>
>>>>>
>>>>> regards,
>>>>>
>>>>> Onno
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>
Re: ValidateForm Event
Posted by Geoff Callender <ge...@gmail.com>.
Beware, there's a long-standing problem with recording errors in
onSuccess().
https://issues.apache.org/jira/browse/TAPESTRY-1972
Geoff
On 02/09/2009, at 7:59 AM, Benny Law wrote:
> Thanks Sebastian. I agree that only business logic related
> validation should
> go into onSuccess, and I would leave basic field validations to
> validators
> as much as possible. My problem with onValidateForm is still the
> amount of
> code I need to write to check for existing errors before I can do
> cross
> field validation. Let me give a quick example:
>
> Suppose I have two date fields, Start Date and End Date. I would use
> the
> built-in validators to check for missing values and invalid dates.
> However,
> in order to cross-validate these dates (to ensure Start Date is not
> later
> than End Date) in onValidateForm, I would need to inject the two
> fields, get
> the tracker from the form, and call inError() to find out if any of
> the
> dates are invalid (missing or bad syntax). If there are no errors,
> then I
> can compare the date properties bound to the fields. Do you see what
> I am
> getting at?
>
> Doing this in onSuccess is a lot easier since I won't need to check
> for
> existing errors, and I know that the date properties bound to the
> fields
> have been updated. Ideally, I would love to have another version of
> ValidateForm event which is fired before Success and only if there
> are no
> errors.
>
> Benny
>
> On Tue, Sep 1, 2009 at 3:39 PM, Sebastian Hennebrueder
> <us...@laliluna.de>wrote:
>
>> Hello,
>>
>> the intended validation method for cross field validation is
>> onValidateForm
>> The onSuccess is probable the latest point to do validation. I
>> would only
>> place business logic related validation in there
>>
>> You may do field validation in the onValidateForm as well but it is
>> normally simpler, faster and cleaner to do this using annotations.
>>
>> If you want to do field validation in the onValidateForm I would
>> not follow
>> the approach of newtonic and write if then statements
>> but to create a simple builder (see Effective Java).
>> Sample without reflection inside of the builder
>> Validator userVal =
>> ValidatorBuilder.required().minLenth(3).maxLength(60).build();
>>
>> usage in onValidateForm
>> userVal.validate(user.getName);
>>
>> You could leverage this using reflection
>>
>>
>> --
>> Best Regards / Viele Grüße
>>
>> Sebastian Hennebrueder
>> -----
>> Software Developer and Trainer for Hibernate / Java Persistence
>> http://www.laliluna.de
>>
>> Benny Law schrieb:
>>
>> Hi Onno,
>>>
>>> I am all for clean and maintainable code, and that's why I think
>>> ValidateForm can be cleaner if I didn't need to check for field
>>> errors
>>> first.
>>>
>>> On the main Tapestry 5.1 page, the Login example calls the
>>> authenticator
>>> in
>>> onValidateForm, but the same example in the User Guide under Input
>>> Validation does that in onSuccess. I think the latter is correct;
>>> the
>>> former
>>> won't work properly because it acts on the properties bound to the
>>> fields
>>> which may not reflect the current field contents if there are field
>>> validation errors. To fix the first example, some code needs to be
>>> added
>>> to
>>> onValidateForm to check if the fields have passed field-level
>>> validations
>>> before invoking the authenticator.
>>>
>>> I hope this clarifies what I am thinking. Thanks.
>>>
>>> Benny
>>>
>>> On Mon, Aug 31, 2009 at 4:57 AM, Onno Scheffers <on...@piraya.nl>
>>> wrote:
>>>
>>> Thanks for your response. Could you explain what you mean by
>>> keeping my
>>>>> validation "in the correct callback"?
>>>>>
>>>>
>>>>
>>>> I think it's about writing clean and maintainable code.
>>>> For other developers reading back your code it makes more sense
>>>> if you
>>>> add
>>>> your validation errors in the ValidateForm event and to perform
>>>> some
>>>> (database?) action in the success handler.
>>>>
>>>> The ValidateForm event is where validation errors are added and
>>>> some of
>>>> them
>>>> are automatically taken care of for you by the Tapestry validator
>>>> mechanism.
>>>> If you don't want to add more than one error-message, you can
>>>> easily
>>>> check
>>>> if the field is in error already.
>>>> Sometimes it also makes sense to add mutiple errors per field since
>>>> you're
>>>> telling the user immediately what (s)he's doing wrong instead of
>>>> having
>>>> them
>>>> re-submit again only to find yet another validation error on the
>>>> same
>>>> field.
>>>>
>>>>
>>>> regards,
>>>>
>>>> Onno
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
Re: ValidateForm Event
Posted by Benny Law <be...@gmail.com>.
Thanks Sebastian. I agree that only business logic related validation should
go into onSuccess, and I would leave basic field validations to validators
as much as possible. My problem with onValidateForm is still the amount of
code I need to write to check for existing errors before I can do cross
field validation. Let me give a quick example:
Suppose I have two date fields, Start Date and End Date. I would use the
built-in validators to check for missing values and invalid dates. However,
in order to cross-validate these dates (to ensure Start Date is not later
than End Date) in onValidateForm, I would need to inject the two fields, get
the tracker from the form, and call inError() to find out if any of the
dates are invalid (missing or bad syntax). If there are no errors, then I
can compare the date properties bound to the fields. Do you see what I am
getting at?
Doing this in onSuccess is a lot easier since I won't need to check for
existing errors, and I know that the date properties bound to the fields
have been updated. Ideally, I would love to have another version of
ValidateForm event which is fired before Success and only if there are no
errors.
Benny
On Tue, Sep 1, 2009 at 3:39 PM, Sebastian Hennebrueder
<us...@laliluna.de>wrote:
> Hello,
>
> the intended validation method for cross field validation is
> onValidateForm
> The onSuccess is probable the latest point to do validation. I would only
> place business logic related validation in there
>
> You may do field validation in the onValidateForm as well but it is
> normally simpler, faster and cleaner to do this using annotations.
>
> If you want to do field validation in the onValidateForm I would not follow
> the approach of newtonic and write if then statements
> but to create a simple builder (see Effective Java).
> Sample without reflection inside of the builder
> Validator userVal =
> ValidatorBuilder.required().minLenth(3).maxLength(60).build();
>
> usage in onValidateForm
> userVal.validate(user.getName);
>
> You could leverage this using reflection
>
>
> --
> Best Regards / Viele Grüße
>
> Sebastian Hennebrueder
> -----
> Software Developer and Trainer for Hibernate / Java Persistence
> http://www.laliluna.de
>
> Benny Law schrieb:
>
> Hi Onno,
>>
>> I am all for clean and maintainable code, and that's why I think
>> ValidateForm can be cleaner if I didn't need to check for field errors
>> first.
>>
>> On the main Tapestry 5.1 page, the Login example calls the authenticator
>> in
>> onValidateForm, but the same example in the User Guide under Input
>> Validation does that in onSuccess. I think the latter is correct; the
>> former
>> won't work properly because it acts on the properties bound to the fields
>> which may not reflect the current field contents if there are field
>> validation errors. To fix the first example, some code needs to be added
>> to
>> onValidateForm to check if the fields have passed field-level validations
>> before invoking the authenticator.
>>
>> I hope this clarifies what I am thinking. Thanks.
>>
>> Benny
>>
>> On Mon, Aug 31, 2009 at 4:57 AM, Onno Scheffers <on...@piraya.nl> wrote:
>>
>> Thanks for your response. Could you explain what you mean by keeping my
>>>> validation "in the correct callback"?
>>>>
>>>
>>>
>>> I think it's about writing clean and maintainable code.
>>> For other developers reading back your code it makes more sense if you
>>> add
>>> your validation errors in the ValidateForm event and to perform some
>>> (database?) action in the success handler.
>>>
>>> The ValidateForm event is where validation errors are added and some of
>>> them
>>> are automatically taken care of for you by the Tapestry validator
>>> mechanism.
>>> If you don't want to add more than one error-message, you can easily
>>> check
>>> if the field is in error already.
>>> Sometimes it also makes sense to add mutiple errors per field since
>>> you're
>>> telling the user immediately what (s)he's doing wrong instead of having
>>> them
>>> re-submit again only to find yet another validation error on the same
>>> field.
>>>
>>>
>>> regards,
>>>
>>> Onno
>>>
>>>
>>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>