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