it also offers basic support for class-level validation.
to mention it once again:
normally extval performs all (simple- as well as cross-) constraint-validations within the validation phase of jsf. however, sometimes it's required to validate after the model was updated. e.g. class-level validations, tree validations,...
to allow these validations this add-on triggers the validation process after the model was updated. furthermore, the original model values of the processed properties (before the model updated) are restored, if there is a violation during model aware and/or class level validation.
in comparison to the full transactional model validation prototype, this add-on doesn't require cglib or spring.
attention: other changes e.g. executed by value-change-listeners,... don't get reverted
1) class level constraints are validated automatically
this mechanism shouldn't be an alternative to jsr 303 - it's just a simple implementation to illustrate the possibility of such a validation. (you are free to implement your own solution based on this mechanism as custom-add-on). moreover, there will be also a similar add-on for jsr 303 class-level validation.
2) a constraint aspect allows a fine-grained definition of constraints which should get validated after the model was updated.
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/examples/advanced/demo_111
shows a simple example.
some details:
that means:
#1 there are constraints which get validated in the validation phase (as usual)
#2 there are constraints (see ModelAwareValidation.class) which get validated after the model was updated
#3 there are class-level-constraints (see the custom @Vehicle constraint)
the pages don't contain validation logic as usual with extval.
so - let's test the application with invalid values:
this means: validation mentioned of #1 happened
this means: within the validation phase only a constraint of first-name was violated -> the other constraints aren't violated or they should be validated after the model update which isn't performed due to a violation in the validation phase.
this means: only constraints of the model-aware-validation are violated - so you see messages you haven't seen so far.so far we haven't looked at the transactional validation behavior of the add-on.
the described invalid tries lead to the following behavior behind the scenes:
try #1 and #2:
no model update
try #3 leads to:
model update:
setFirstName: Gerhard
setLastName: P
setManufacturer: MyCar
setModelIdentification: MyCar
violation during model aware and (/or) class-level validation:
-> revert new model values
setFirstName: null
setLastName: null
setManufacturer: null
setModelIdentification: null
in this case null was the last valid model value of all properties (since we haven't had values in the model).
you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/transactional_model_validation_light
