Overriding process is much worse than having validate() non-final, so
lets go for that. Btw, I think it is a good idea have
findSubmittingButton final protected anyway, as it is a very convenient
method anyway.
If no-one objects to making validate non-final, I'll commit it.
Eelco
Cameron Braid wrote:
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
-------------------------------------------------------
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
