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