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