[preview] early preview of the 4th release

the current milestone already offers a lot of the features which will be available in the 4th release. the 4th release will introduce new features for the validation modules as well as some performance improvements and an improved jsf 2 support. until the next release, we will also improve the documentation. so it will take some time to get out the next version of extval. anyway, the current milestone is already quite stable and used in several applications out there.

once again extval (1.x and 2.x) offers features which aren't available in other validation frameworks for jsf. e.g. extval allows to use @Valid in combination with jsf. beyond the features of bean-validation (jsr 303) itself extval provides the possibility to use an annotation called @ConstraintSource. it allows e.g. to annotate dto's with this new annotation(s) in order to specify the source which hosts the constraints. so you don't have to repeat all the constraints in classes like dto's.

[add-on] customizable severity feature and the continue with warnings add-on

the next version of extval will offer violation severities for constraints via extval-validation parameters as well as via jsr303 payload parameters. that means it's possible to define the severity for every constraint.

sometimes it is needed that you can save the form-data and continue in the application even though there are still warnings. so version x.x.3 (for jsf 1.x and jsf 2.x) of extval will allow that you can change the behavior (depending on the severity) via a custom add-on.

that means:
the user tries to submit invalid data. there are just warnings and no errors. so the page gets refreshed and the warnings are displayed. so far we have the expected jsf behavior. if the user clicks again on the (same) button the add-on recognizes that the user already saw the warnings and if there are no errors the warnings are ignored this time. the usage is quite simple:

the required steps:

add extval to the project
add the add-on to the project

use the constraints
from extval:


or from jsr 303


and within the form you just have to add the following hidden field:


that's it!

if you would like to have a button which is still strict and doesn't continue with warnings, you can use a special parameter. since the implementation of the add-on is quite simple it's also possible do implement it the other way round.

optional for the strict behavior:


the add-on is available at: http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/continue_with_warnings and requires the current trunk version of extval (or the next milestone v.1.2.3M2)

[preview] client-side validation with jsr 303

after updating to the newest ri-version of bean-validation (jsr 303) i added some new functionality to the bean-validation (integration) module of myfaces-extval. the "new" functionality is already known from previous releases of the property-validation module. currently it works with jsf 1.x., however, there is also a branch for jsf 2.0 which will be updated before the next release.

so i started to refactor the featureset-01 example (which is already shipped with myfaces-extval) to bv-constraints. since myfaces-extval provides ui-optimized approaches not everything will be possible. anyway, the result of this first step is client-side validation of @NotNull and @Size via the client-side validation feature of myfaces trinidad.

the rendered result:


as you might already know extval also initializes the component based on constraints. that results in the correct values e.g. of the maxlength attribute - a section of the page above:


this example uses the same xhtml pages like featureset-01 - so the important part of the facelets-component is:


and the most important part - a section of the entity:

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!

[preview] typesafe constraint aspects

the problem

@Required(parameters = {
@Param(key= "severity", value = "warn"),
@Param(key= "display", value = "global")})

... this version allows you to add general information to a constraint. you can think about it as an extension point for constraints. anyway, a string-based approach has some disadvantages.

e.g.:
- not typesafe
- you have to know key/value combinations (no auto-complete offered by the ide)
- refactorings can break your implementation
- ...

so that's quite error prone...

the solution

@Required(parameters = {
ViolationSeverity.Warn.class, DisplayGlobal.class})

such constraint aspects offer a typesafe alternative e.g. for parameters. so you can provide an extval add-on without knowing the concrete constraint implementation.
only the central logic (e.g. of an add-on) has to know what information might be available as parameter at the constraint and how to use this information.

so you can have add-on-x which provides new features and constraints y (they don't know each other). but you can use the features of add-on-x with constraints y (if the constraints have an attribute of the type Class< ? extends ValidationParameter>[])

there are different supported styles. some information are available in the wiki. compared to using strings - it's a bit more effort to create such a parameter implementation. anyway, you don't frequently create new parameter implementations. but you will frequently use them. as you saw - the final usage is typesafe, short and the constraint isn't aware of the specific values behind.

so if you have existing constraints you just have to add an attribute of the type Class< ? extends ValidationParameter>[] and your constraint can automatically join any feature provided via a parameter implementation of extval, an extval add-on or your custom implementation.

[preview] early preview of the 3rd release

within 2 releases myfaces extval grew up to a very powerful validation platform which is used in several real-world projects. due to that extval solves real-world problems. the pluggable architecture allows you to implement fancy add-ons to provide functionality which isn't available out-of-the-box and wouldn't be possible with the standard validation mechanism offered by jsf. so the question is: "what's next?"

here is a short preview of some new features of the next release. it's a quite early preview. so i might update this post, if there are some new information.

the "big" parts:

#1 jsr 303 (bean validation) validation module
that's a new validation module for extval which allows the unified usage of jsr 303 with jsf 1.x and jsf 2.x
(jsf 2.x has jsr 303 support out-of-the-box. anyway, this adapter will offer some additional typesafe features)

#2 jsr 314 (javaserver faces 2.0)
there will be a new core version which allows you to use extval with jsf 2.0
so you can continue to use your constraints, add-ons,... with the next version of jsf!
(you will just have to update the modules you are using right now. your implementations remain the same.)

some of the smaller but nice new features:

#3 typesafe constraint aspects (= generic parameters)
such aspects allow you to extend the functionality of existing constraints.
furthermore, they allow to introduce shared features. it's also used as base for the next feature.

#4 none-blocking warn mode
several users asked for a "warn mode". that means: a constraint violation is acceptable for the moment. so the severity of the faces message is switched e.g. to warn. furthermore, it doesn't result in a validator-exception. so the jsf lifecycle continues normally and your actions,... get executed.

the syntax isn't final now - the currently available implementation is e.g.:

@Required(parameters = ViolationSeverity.Warn.class)

the parameters-attribute comes from #3 and isn't aware of the severity aspect.
the parameter concept is key/value based and typesafe (any type is allowed!)
a constraint which supports such generic parameters automatically joins available mechanisms/implementations. that means e.g. add an attribute to your constraint with the type Class< ? extends ValidationParameter >[] -- that's it. without additional implementation you can join such features like the warn-mode.

#5 more out-of-the-box available points for intercepting the validation process

#6 solution for your requirements
extval was started to solve common requirements of users. all parts of the framework are inspired by common real-world requirements. so feel free to ask for new features, add-ons,...

as you see some of the features depend on other releases like the ri implementation of jsr 303. so it's hard to predict the release date.