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
