Sunday, May 31, 2009

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

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

Wednesday, May 13, 2009

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: