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.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 <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
