extval meets paper

bart kummel wrote a book about the myfaces project.
i'll publish a review about the book quite soon.

it also contains an intro of myfaces extval!
it's really great that the extval chapter is the free sample chapter.
so enjoy reading it!

extval r3 in action - fullstack 2010

this fullstack demo illustrates some use-cases of using jsf 1.2, spring 3, myfaces extval r3, bean-validation,... in case of myfaces extval the demo also shows how to keep all layers outside the view-layer independent of extval classes. so you see how to re-use existing (extval independent) constraints for ui validation in a typesafe way.
furthermore, the demo shows how to integrate bean-validation (jsr 303) in jsf 1.x applications.

further details are available in the (short) readme file.

here is the list of the used technologies:
- jsf 1.2 (+ facelets)
- myfaces orchestra
- myfaces extval r3 (+ some add-ons)
- bean-validation (jsr 303)
- spring 3
- jpa 1.0
- primefaces

[add-on] spring 3 managed constraint validation for extval

there is a new add-on which allows using typesafe spring 3 dependency injection for constraint validators. so it's possible to inject other beans (e.g. a validation service, a repository,...) into a constraint validator.

it's similar to the native extval di support. the main difference is that the add-on offers a typesafe alternative. you just have to extend the default-implementation (listed at @Constraint(validatedBy = {...})) and provide the custom implementation as spring bean.

os890 maven repository

it was a frequent user request that the myfaces-extval add-ons should be available via a maven 2 repository. so i created a repository for os890 as well as for sandbox890.

so you just have to add e.g. the following part to the repositories section of your pom.xml

<repository>
  <id>os890.googlecode.com</id>
  <url>http://os890-m2-repository.googlecode.com/svn/tags/os890</url>
</repository>

snapshots are available via

<repository>
  <id>os890.googlecode.com</id>
  <url>http://os890-m2-repository.googlecode.com/svn/trunk/os890</url>
</repository>

further information are available in the usage-wiki as well as the repository overview!

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

myfaces-extval-add-on - app-prototyping - 2

due to a valid user request (a possible combination with spring security) also the functionality of the extval app-prototyping add-on (and more) will be available in the next release. early adaptors can use the current svn version or the next milestone (m2) which will be available soon.

the add-on won't be obsolete. there will be new functionality!

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.

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

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:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/advanced_metadata

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:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/conditional_metadata_exclusion

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:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/virtual_metadata

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:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/metadata_priority

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:
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

myfaces-extval-add-on - app-prototyping

today i received a request of a myfaces extval user.

the question was how to use myfaces extval in a prototype with input components without value bindings.

the solution is an add-on which is available at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/prototyping

myfaces-extval-add-on - @SecuredAction

you might already know that you can use myfaces extval for much more than validation. this new add-on shows how simple it is to provide add-ons for different problem domains. it's available at http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/secure_actions.

@SecuredAction is an annotation to secure the execution of action methods. it's independent of the concrete command component and offers several features. normally you can secure such actions via the rendered attribute. however, maybe you would like to restrict method execution based on new model values (which were updated at the same request). there are several other use-cases where you can use it instead of the required attribute of the command component. at least it is a feasibility study for further extval add-ons.

the base idea is similar to the @RolesAllowed of tobago. this extval-add-on offers a bit more than a role check. if you are just interested in the same functionality without using tobago, it's quite easy to add an "allowedRoles"-attribute as well. it isn't implemented out-of-the-box, because the existing approach of permittedIf-conditions is much more generic.

@SecuredAction offers several features - here are some short examples:


that means:
if one of the condition(s) returns false the "deny"-method is called instead of the annotated method. also the optional return-value is used as expected. so you can execute custom logic in case of denied access.

the following example shows a shorter syntax for the "deny"-method. it's possible to refer a local method directly:


it's also possible to overrule the outcome. the following example forces to redisplay the same page instead of displaying a different one:


furthermore, in case of denied access, you can automatically add a (global) error message via:


the add-on automatically looks at the same package of the class (which hosts the secured action method(s)). the name of the resource bundle is: securty_messages. it's just for demo cases. for real word usages you can register e.g. an existing bundle within an extval-startup listener. you can register a message-bundle base-name or for jsf 1.2+ also a message-bundle var-name.
sample:

//use an existing message bundle
ExtValContext.getContext().addGlobalProperty(
SecuredAction.MESSAGE_BUNDLE, "at.gp.demos.messages.my_messages");

//use an existing message bundle var-name
ExtValContext.getContext().addGlobalProperty(
SecuredAction.MESSAGE_BUNDLE, "#{myMessages}");

in the message bundle you have to add a summary and detail message - e.g.:
action_not_allowed = action not allowed
action_not_allowed_detail = action not allowed - please switch the role

the default case is that @SecuredAction doesn't change the lifecycle execution. via an additional attribute it's possible to change that. the following example always leads to an execution (of the secureAction) in the "apply requests values"-phase. if it's permitted to call the secured method, the original lifecycle execution also doesn't change in this case.


it's also possible to define specific pages which need a secured action method:


to define different scenarios, it's possible to use multiple annotations at one method. you can do that via:

myfaces-extval for highlighting validated fields without additional/special components

you can find a short demo case for highlighting validated fields without additional/special components at example 105

the result looks like:

myfaces-extval-add-on - @BypassValidationController

the bypass validation add-on for extval was updated!

beyond the action-method based bypass it's possible to bypass validation with an annotation which is similar to a view-controller annotation. anyway, it works the opposite way round. if the annotation is used validation is bypassed.

you can use the annotation on the first bean (= page/backing bean), the first property (of the page/backing bean), the last base object (owner of the property) and the bound property.

that means something like:
#{pageBean.bean1.bean2.person.firstName}
the green parts are possible targets for @BypassValidationController

a simple example:
that leads to:

1) bypassed extval-validation for every property bound via: #{personPage2. ...}

attention: only skipable validations are bypassed by default. so e.g. jpa based validation continues to work. if you would like to really bypass everything, you have to use:
@BypassValidationController(@ViewId(all = true))
instead.

2) bypassed extval-validation for every property bound via: #{personPage2.person ...}
but only for the view-id "/pages/new_person2.xhtml" + the given condition is true.

it's important to mention that the 4 possible targets for @BypassValidationController are optional. e.g. it's possible to annotate a property without annotating the class itself. furthermore, there are useful default values for all attributes.

myfaces-extval-add-on - @BypassValidation for action methods

there is a new add-on for myfaces-extval.
it's hosted at [1] and a sample application is available at [2].

[intro]
normally you have to validate all bound properties.
extval provides out-of-the-box a skip validation feature.
if one of the expressions of @SkipValidation returns true, validation of skipable validators gets canceled (the validation strategy has to be marked with @SkipValidationSupport).

anyway, sometimes you need actions which aren't immediate but they have to get executed without validation. therefore this add-on provides @BypassValidation

[new]
just add the add-on to your classpath and annotate these special action methods - example:


@BypassValidation
this simple case bypasses all skipable validations, if the annotated action method will be called.
-> e.g.: in this case @Required doesn't get validated whereas db constraints like nullable = false and length are validated in any case. (see the next usage, if you would like to bypass everything. however, please notice that it might lead to an exception if you try to save an invalid entity. so it's better to use all = false)

if you would like to bypass all validations use:
@BypassValidation(all = true)

furthermore, you can provide one or more optional el-expressions.
so it is possible to bypass validation just if one of the conditions returns true.
@BypassValidation(
condition="#{currentUserRole.privileged}")

requirements: myfaces-extval 1.x.2-SNAPSHOT+

[1] http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/bypass_validation

[2] http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/examples/basic/demo_009

myfaces-extval config extension

there's a new external module for myfaces-extval.

it provides an alternative configuration approach for extval.
this extension allows to configure the following artifacts via annotations:
- StartupListener
- ValidationStrategy
- MessageResolver
- ComponentInitializer
- MetaDataTransformer
- InformationProviderBean
- ProcessedInformationRecorder
- RendererInterceptor

since extval 1.x.2:
- MetaDataExtractionInterceptor
- NameMapper
- FacesMessageFactory

you will find further details in the provided README.txt
it's available at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/annotation_based_config