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

Reply via email to