Saturday, June 20, 2009

myfaces-extval-add-on - transactional model validation light

this add-on is a prototype for lightweight transactional model validation.
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.

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: