Actually - I have found a use case for needing to provide a custom Form.valdate() method.
I am building a grid edit component. It works in batch mode - for editing a whole list of objects at a time. Each row has a 'delete' checkbox. What I need to do is ignore the rows flagged as 'delete' during the validation step. I tried to work it such that I removed the validation messages that were created during validate - however there is no support for removing validation messages once they have been created. And doing it this way also seems backward. I then tried to implement it using a custom Form.process method, replacing the call to validate() with my validateNonDeleted() - however to achieve this, the following changes are needed : findSubmittingButton and persistFormComponentData need to be changed from "private" to "final protected" to allow subclasses to call them. Also - submittingButton.onSubmit() cannot be called from subclasses of Form, since its protected. I think that making Form.validate() non final, and describing the issues in the javadocs may be the soloution. Unless you can point out an alternative ? Cheers, Cameron. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:wicket-develop- > [EMAIL PROTECTED] On Behalf Of Eelco Hillenius > Sent: Monday, 25 July 2005 1:06 AM > To: [email protected] > Subject: Re: [Wicket-develop] Form - custom form level validation > > Cameron Braid wrote: > > > I wish to implement form level validation, and was wondering that the > > recommended approach is ? > > > > I would like to be able to do this validation before Form.onSubmit() - > > since I would like to prevent the model from being updated in the case > > of invalid input. > > > > Form.validate() is final. So either this needs to be changed, or a > > different soloution could be implemented : > > > > Some ideas : > > > > 1) validate() could call a new template method validateForm(). > > > > 2) enhance Form to support adding IFormValidator instances, and > > process them after processing the form components's IValidator > instances. > > > > Cameron. > > > > Actually, I recently added IFormValidator to Wicket. I removed it again, > as I thought it was too difficult to use, and left too much to argue. > Most important thing I struggled with was the updating of form > components. Usually, when you do form level validation, you want to work > with the updated model, e.g. to compare properties with each other. > However, if validation fails, you generally want to rollback the model > updates. The problem with implementing this however, is that we cannot > guarantee such rollback, as each form component update could lead to > model changes outside of the component's normal model. Another problem > is that it is quite heavy to make copies of all form component models, > and as it must be done with serialization, it is quite error prone too, > as it is perfectly acceptable to have non-serializable data in > detachable models. > > So... I'm off the 2) path. > > 1) might be an idea but we have to agree on that this must be called > after the form component validation but before any model updating. > > I actually thought about implementing such a template method, but > expected to get a lot of questions when people would start using it > regarding the models not being updated (again, I think this is usually > what you want when doing form level validation). > > What I did do however, was introduce template method > beforeUpdateFormComponentModels, which is (tada) called right before the > form component model updating starts. You can override this method to > record any rollback data, en just do the validation in your form's or > button's onSubmit method. In that method you can set any messages > directly (just call error on the form, or on the target form component). > When you have errors, you can decide whether any rolling back should be > done (when you work with detachable models that pull their data from > some external source, this is usually not nescesarry), and you can then > just render the same page again (which is the default). > > So... I don't thing we really need 1) either. Or.. could you come up > with a pattern that is clear, consistent and easy-to-use that doesn't > have the but.. parts I described above? > > Eelco > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Wicket-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-develop ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
