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:
ExtValContext.getContext().addGlobalProperty(
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:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/metadata_provider
