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
all parts of the trinidad support are available within an own module.
to enable the trinidad support you just have to add myfaces-extval-trinidad-support-1.*.jar to the classpath.
it provides e.g. client-side validation. this means that client-side trinidad validation gets based on annotations (the simple extval annotations and jpa annotations). it's also possible to use client-side validation based on custom annotations. moreover, this approach allows to reuse implementations of existing client-side trinidad validators.
the trinidad support shows how extval is able to use client-side validation features of component libs in a very easy way.
myfaces core12 < v1.2.4 has a bug. a workaround to use extval with these versions is available at http://code.google.com/p/os890/source/browse/trunk/java/web/jsf/extval/myfaces-core12-workaround/CrossValidationMyFacesFixPhaseListener.java
information for users of myfaces-core 1.2.4+ don't need this workaround for these releases.
today i imported the refactored implementation of sev-en into the upcoming myfaces-extensions project. the official name is myfaces-extensions-validator. however, i'll use the abbreviation myfaces-extval.
as mentioned within the previous post: sev-en has zero required configuration and offers some powerful features such as cross-component validation and extensibility (e.g.: easy custom validation).
the following part illustrates some of these features. the example uses facelets and trinidad. however, these technologies are not required! (sev-en supports property and field access.)
sample scenario - the target: => first name != last name => birthday is (of course) before the final exam => old nick name != new nick name (with a direct reference to the old value) => old password != new password (without a direct reference to the old value) => new password == re-entered new password => each input-field is required (within the domain model: re-use jpa annotations) => restrict the max. length of string values (also re-use information of jpa annotations)
now hold on a moment and think about the effort of doing such validations.
without sev-en: the simple parts of the scenario above can be solved with the according tags. if you are using jpa annotations, you already have some of these information within your mapping. -> redundancy (annotations + tags). ok - let's have a look at the more complex validation scenarios. i'm referring to the date and password validations. there might be e.g. some password components available. does your component lib offer such a feature? ok - nice, if you are one of the lucky one's. however, what's about the next complex requirement within your project? - there might be no adequate component within the available component libs. or are you using one of the unaesthetic workarounds?
sev-en provides a lot of powerful solutions.
the registration page:
the page to change the nick name:
the page to change the password:
... oh - it's really straightforward!
the page bean class (backing bean):
... oh - some new annotations - however, it's also really straightforward! we aren't using jpa annotations here (it's the view layer!)
the domain model class:
... really nice - some simple jpa annotations which are also used for validation. you aren't using jpa? no problem - you can use conventional validation and/or you can use the sev-en standard or custom annotations ;)
the following screenshot shows an example of a failed validation:
sev-en isn't about specific annotations. sev-en is mainly the core itself. out-of-the-box sev-en will provide some separated modules with nice annotations.
one of the next posts will be about the really easy way to implement custom sev-en annotations.
it stands for: simple enhanced validation with extensible nature
the base idea was to start a feasibility study about annotation based jsf validation. e.g. it should be possible to re-use jpa annotations for validation. last weekend i finished the first prototype.
current main-features: - cross-component validation (including cross-entity validation) - support for jpa based validation - extensible (e.g. custom annotations and all important parts of the core) - zero configuration
within the next view weeks i'll provide further details.