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 o...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ValidateForm Event
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 use...@laliluna.dewrote: 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 o...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ValidateForm Event
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 use...@laliluna.dewrote: 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 o...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ValidateForm Event
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.jumpst...@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 use...@laliluna.dewrote: 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 o...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ValidateForm Event
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.jumpst...@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
use...@laliluna.dewrote:
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 o...@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
Re: ValidateForm Event
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.jumpst...@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.jumpst...@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
use...@laliluna.dewrote:
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 o...@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
Re: ValidateForm Event
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
Re: ValidateForm Event
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 o...@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
Re: ValidateForm Event
Hi,
To keep all your validation in onValidateForm, I something like this.
String onValidateForm()
{
if(userName == null )
{
form.recordError(usernameField, Needs a Username)
}
if(password == null )
{
form.recordError(passwordField, Please Enter a password)
}
if(!form.getHasErrors()) {
if (!authenticator.isValid(userName, password))
{
form.recordError(passwordField, Invalid user name or
password.);
}
else
{
//set applicationstate user object
}
}
}
Object onSuccess()
{
//here you can return whatever page you forward after login.
return IndexPage;
}
Benny Law wrote:
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 o...@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
--
View this message in context:
http://www.nabble.com/ValidateForm-Event-tp25205192p25226000.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ValidateForm Event
Thanks for your response. Could you explain what you mean by keeping my validation in the correct callback? Benny Law On Sun, Aug 30, 2009 at 1:40 AM, newtonik newto...@gmail.com wrote: I think you should use the onValidateForm for both field level and cross-field validation to keep your validation in the correct callback. I would just use nested loops to first check for field level validation then if successful, perform cross field validation. Benny Law wrote: Hello, I am new to Tapestry 5 and have a question about the ValidateForm event. I understand that this event is where cross-field validations should be done, but I find that before I can do the validations, I first need to check if there are any field-level validation errors with those fields that I want to cross validate. To avoid this extra work, I end up doing my cross-field validations in the Success event instead. It seems to me that the ValidateForm event would be more useful if it was triggered only when there are no field validation errors, similar to the Success event. Did I miss something, or are there others who share my view? Thanks in advance, Benny Law -- View this message in context: http://www.nabble.com/ValidateForm-Event-tp25205192p25208900.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
ValidateForm Event
Hello, I am new to Tapestry 5 and have a question about the ValidateForm event. I understand that this event is where cross-field validations should be done, but I find that before I can do the validations, I first need to check if there are any field-level validation errors with those fields that I want to cross validate. To avoid this extra work, I end up doing my cross-field validations in the Success event instead. It seems to me that the ValidateForm event would be more useful if it was triggered only when there are no field validation errors, similar to the Success event. Did I miss something, or are there others who share my view? Thanks in advance, Benny Law
Re: ValidateForm Event
I think you should use the onValidateForm for both field level and cross-field validation to keep your validation in the correct callback. I would just use nested loops to first check for field level validation then if successful, perform cross field validation. Benny Law wrote: Hello, I am new to Tapestry 5 and have a question about the ValidateForm event. I understand that this event is where cross-field validations should be done, but I find that before I can do the validations, I first need to check if there are any field-level validation errors with those fields that I want to cross validate. To avoid this extra work, I end up doing my cross-field validations in the Success event instead. It seems to me that the ValidateForm event would be more useful if it was triggered only when there are no field validation errors, similar to the Success event. Did I miss something, or are there others who share my view? Thanks in advance, Benny Law -- View this message in context: http://www.nabble.com/ValidateForm-Event-tp25205192p25208900.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
