Wednesday, June 24, 2009

myfaces extval and seam

you might have looked at my first comparison of extval and the seam 2.x integration of hibernate validator [1]. some of you were interested in a seam support of extval to get the best of both frameworks.

i've tested extval with seam and it worked quite well. to use extval also with richfaces the generic-support module of extval is required. some weeks ago the test with myfaces core was successful. there is just an issue with the combination of (richfaces + extval + mojarra). if you would like to use this combination, feel free to look into the issue and provide some details and/or a patch to fix it.

furthermore, it's possible to use both solutions in parallel.

Sunday, June 21, 2009

extend myfaces extval with your own concepts

it's important to know that extval is able to help you with every possible validation requirement (in view of jsf). if there isn't an out-of-the-box functionality, extval provides a solid base to build your own custom concept. several add-ons already proved that. you can just use them. however, they should basically show that it's quite easy to extend extval. (furthermore, you can integrate a 3rd party validation engine. the first public integration is the integration module of jsr 303 (it will be released after the final release of jsr 303 itself).)

if you miss a feature, just ask if there is already an add-on which solves your requirement(s). some of you already told me nice ideas and i implemented add-ons as possible solutions. however, there are also other solutions to solve these and other requirements. feel free to impl. your own add-on and send me a short e-mail about it :)

the 3rd release will introduce further base concepts. i wrote about constraint aspects and much more. i also impl. some short examples to show that it is pretty easy to extend and re-use the solid base of extval.

let's have a look at a possible scenario:
you would like to use a partial validation concept similar to the mechanism available in jsf 2.0. but extval doesn't provide group validation out of the box. moreover, you don't like the typesafe validation-controller-annotation of some of the available add-ons. you prefer to use a tag-based solution instead? no problem. some lines of code and here we go :)

do you think it's too much effort to impl. your own concept based on out-of-the-box functionalities? see for yourself how easy it is! demo 112 illustrates a simple impl. of the mechanisms mentioned above.

so have fun with extval!

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:

Friday, June 12, 2009

myfaces-extval-add-on - advanced metadata

this add-on is a collection of some metadata add-ons. you can still use the other add-ons independently. anyway, this collection allows some internal improvements and you don't have to care about possible side-effects. it just works.

currently the add-on combines:
- metadata provider
- virtual metadata
- conditional metadata exclusion
- metadata priority

the combined usage at your properties (of all included add-ons) looks like:

the separation is of course optional - since it's a feature of one of the add-ons, it's used in this example.

you can find the add-on at:

myfaces-extval-add-on - conditional metadata exclusion

extval allows to include and exclude metadata dynamically. currently there are already a lot add-ons out there. this add-on allows to exclude metadata conditionally in a fine-grained manner. furthermore, it's possible to use it for 3rd party annotations as well.

the usage at your properties looks like:

if you have multiple target conditions the usage looks like:

you can find the add-on at:

myfaces-extval-add-on - virtual metadata

maybe you thought - extval supports 3rd party annotations (e.g. jpa based validation) and the new typesafe constraint aspects aren't available for 3rd party constraints.

the virtual metadata add-on solves this restriction.

the usage at your properties looks like:

you can find the add-on at:

Thursday, June 11, 2009

myfaces-extval-add-on - metadata priority

this add-on allows to force a validation priority (independent of the used order).
it's especially useful for the metadata-provider add-on. so you can prioritize the found constraints. anyway, it isn't bound to the other add-on - so you can use it independently.
(or impl. your own add-on - it's quite simple)

simple example:

you can find the add-on at:

Tuesday, June 9, 2009

myfaces-extval-add-on - metadata provider

this time don't look at the images before your have read the text. it's really important to understand the special use-cases!

basically this add-on shows how to add constraints from an alternative source to the current validation-process. it's possible since extval 1.x.2 via a custom MetaDataExtractionInterceptor. this add-on uses special java-classes as alternative source. however, you can use e.g. xml files,... as alternative source. it's up to you - the way you have to do it is more or less the same.

one idea of metadata based validation is that you have the constraints where they belong to. jsr 303 will allow to define cross-layer constraints (by definition). extval allows the same. anyway, if you have view-layer centric constraints e.g. the out-of-the-box available extval constraints (just the dependency itself is view-layer specific) and your architecture doesn't allow to use them in your entities, you have ~5 choices:

1) only use the jsr 303 support of extval x.x.3+
disadvantage: less features (due to jsr 303 itself)!!!

2) implement your own set of constraints:
advantage: they have no dependency to extval - but you can use extval to validate them in jsf applications. since they don't depend on extval, you can use your own validation engine in the other layers or ... (too much possibilities for this post)

disadvantage: you have to implement, test, maintain,... them

3) use the metadata-provider add-on (or impl. a similar one)
advantage: use existing constraints outside your entities and bind it to the entities in a typesafe manner...

disadvantage: depends on your opinion

4) change your architecture
normally that isn't a real option.

5) don't use extval
do you think that it is a nice option for your jsf-application? i don't think so ;)

you still read this entry - so you are interested in the approach of the add-on :)

just to mention it again - extval allows to validate any constraints. that's a base principle. extval introduces no requirement to your constraints. you can also provide validators for your existing constraints... so you can use constraints which have no (in-/)direct dependency to extval. that's a base principle! but maybe you have special constraints just for your view-layer or you have to bind your fields against existing implementations or you are using something like dto's or ... . this add-on solves possible architecture issues you might have had so far and demonstrates alternative constraint sources in general.

your entity:

the decoupled style via name convention:
the convention is: place it in the same package + the MetaData postfix.

possible issues after refactoring of your application:
- property names of the entity might change (-> use the extends * approach of the following style)
- the class name/location might change (-> you need the 2nd approach)

-> to solve both there is an alternative approach:

the typesafe version:
... you extend the target (entity) and override the properties which are the targets for the ui-specific constraints. the add-on uses scannotation to discover such classes. so you can use any package and class-name. if you refactor the person class e.g. lastName -> surName your ide should automatically rename the overridden properties as well (at least @Override helps you to detect errors). so it's a really typesafe approach. (you have to provide the target class as value of @MetaDataProvider - this might change in the final version)

optionally you can use:
MetaDataProviderStorage.KEY, "your package");

within an extval startup-listener to define a custom package to scan.

in your application you add extval, the add-on and your metadata provider classes to your jsf application. if you have other modules for the other layers, they aren't affected!

so if the only argument against extval/constraint based validation was that you aren't allowed to use the out-of-the-box annotations or ..., you see how the solution could look like (or just use it). and be happy, if you don't have such requirements and you can just use extval as it is :)

you can find the add-on at: