[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.

[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.