myfaces-extval MetaDataStorageFilter and @JoinValidation

beside some other improvements a new concept will be available with the next milestone.

a generic storage concept is used to cache the basic meta-data.
all mechanisms which allow dynamic meta-data remain the same. instead of caching the final meta-data for a property just the basic meta-data gets cached. the meta-data which is extracted from the original property. as an addition to the existing dynamic meta-data mechanisms a new concept is available. in comparison to a MetaDataExtractionInterceptor the new MetaDataStorageFilter is just invoked before meta-data gets added to the storage.

it's an additional extension point which allows you e.g. to introduce new functionality which isn't available out of the box.
the property-validation module of extval uses such a filter to introduce a new syntax for @JoinValidation. so it's possible to use a static syntax instead of the dynamic possibilities.

some nice syntax examples are available at one of the example classes.

so maybe you ask - MetaDataStorageFilter are fine but all i need is already possible via a MetaDataExtractionInterceptor. why do i need such filters? yes that's right, however, the new filter concept in combination with the meta-data-storage allow a better performance.

MetaDataExtractionInterceptor ... use them if you have to decide to add/remove/change meta-data very dynamically - e.g. based on the current program-flow, app-state,...

MetaDataStorageFilter ... use them if you would like to introduce a custom but static concept and benefit from the better performance

myfaces-extval-add-on - app-prototyping - 3

since the original functionality was promoted and will be part of the next version. i added a new functionality. it might be the case that you have issues while prototyping. if so, please report them to the mailing list. anyway, normally you would have to remove extval from the classpath so that you can continue your work. that's due to the zero config approach of extval. you can deactivate it via api's but now you have a further possibility.

the current trunk version (= the next milestone) allows to provide a custom implementation of the extval-context. that allows to introduce alternative approaches e.g. using a dependency injection framework like spring and google guice for internal tasks as well as registering artifacts via dependency injection.

it also allows to mock the extval context. so you can deactivate all/specific features easily. an example is available at [1]. since you have to configure a custom extval-context manually (the class provides the needed information to do it), you can add it to your project permanently. if you would like to check something without extval, just activate the config and afterwards you can remove it again. as mentioned before, it also allows to deactivate specific features easily without using web.xml context-parameters.

anyway, normally you shouldn't have problems. if you find issues, please report them as soon as possible.

[1] http://code.google.com/p/os890/source/browse/trunk/java/web/jsf/extval/prototyping/org/apache/myfaces/extensions/validator/custom/DevExtValContext.java

myfaces-extval java-config extension with gooogle guice style

why you might need this add-on

there are many different approaches to configure myfaces-extval.
out-of-the-box it uses zero configuration (convention over configuration) as well as an optional java-api which is mainly for internal usages and add-on developers.

so os890 provides an annotation based config add-on. so you don't have to learn the name conventions and the result is typesafe.

the disadvantage is that classpath scanning is required. you can specify packages to be scanned. anyway, it uses an external lib which performs the classpath scanning.

that's the reason for creating an additional add-on which is typesafe and doesn't use an external lib. as mentioned before extval provides an api and a generic artifact mapping mechanism which is used mainly for internal purposes. you can see the usage in the source-code of some add-ons. anyway, app-developers who don't like conventions need a simple but powerful api which is available for the common artifacts.

google guice provides a nice api to bundle modules. so the api of the add-on is similar to the style of google guice. that means you build modules and register the modules you would like to use.

the usage
first you implement a module. in a module you register global artifacts or you bind together a validation strategy with one or more of the following artifacts: constraint, message resolver, meta data transformer.

the following example shows both:


you just have to add your global artifacts or bind together artifacts which have a relationship. so you see that the syntax is quite easy.

via an extval startup listener you can register one or more modules easily.

the result
it's typesafe, explicit, flexible without external dependency and easy to use.
it's available at http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/java_based_config

a working example is available at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/examples/basic/demo_010