That looks very reasonable. I think I will adopt this approach. Thanks Geoff.
Benny On Wed, Sep 2, 2009 at 1:02 AM, Geoff Callender < geoff.callender.jumpst...@gmail.com> wrote: > 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 >>>>> >>>>> >>>>> >>>>> >>> >
