the apache myfaces team is pleased to announce the first release of myfaces-extensions-validator!
released versions:
extval 1.1.1 (for jsf 1.1.x)
extval 1.2.1 (for jsf 1.2.x)
Friday, December 12, 2008
Friday, October 24, 2008
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
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
Thursday, September 25, 2008
myfaces-extval meets myfaces-trinidad
yesterday i added a much better trinidad support.
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.
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.
Tuesday, September 16, 2008
myfaces-extval got independent of cglib
some days ago i introduced a new mechanism which replaces the cglib approach.
so some proxy drawbacks of the old approach are solved.
so some proxy drawbacks of the old approach are solved.
what changes for the user:
you just have to check the compatibility with your component lib.
old:
requirement of the cglib approach:
component and converter creation via the jsf application.
new:
requirement of the new approach:
all input components have to call the method getConvertedValue.
(a method of javax.faces.render.Renderer)
you just have to check the compatibility with your component lib.
old:
requirement of the cglib approach:
component and converter creation via the jsf application.
new:
requirement of the new approach:
all input components have to call the method getConvertedValue.
(a method of javax.faces.render.Renderer)
what's the workaround, if a component lib doesn't do that so far?
it's still possible to use the cglib approach or the adapter fallback approach of the alternative module.
it's still possible to use the cglib approach or the adapter fallback approach of the alternative module.
how do i reactivate the cglib approach?
just add myfaces-extval-alternative-1.x.x-SNAPSHOT.jar to the classpath.
that's it!
just add myfaces-extval-alternative-1.x.x-SNAPSHOT.jar to the classpath.
that's it!
Monday, July 14, 2008
myfaces-extval and myfaces-core12 < v1.2.4
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.
information for users of myfaces-core 1.2.4+ don't need this workaround for these releases.
sev-en continues at myfaces
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.
Sunday, June 8, 2008
sev-en meets myfaces
some weeks ago we (the myfaces community) decided to add sev-en.
last week there was a successful vote that there will be a new sub-project called myfaces-extensions.
myfaces-extensions will contain:
- myfaces-extensions-aspectel
- myfaces-extensions-validator (aka sev-en)
- myfaces-extensions-scripting
last week there was a successful vote that there will be a new sub-project called myfaces-extensions.
myfaces-extensions will contain:
- myfaces-extensions-aspectel
- myfaces-extensions-validator (aka sev-en)
- myfaces-extensions-scripting
Tuesday, April 15, 2008
sev-en preview - new version
within the last few days i refactored sev-en. the most significant change: sev-en doesn't need the generated adapters.
Monday, April 7, 2008
sev-en preview - re-use existing annotations
today i added a new annotation to the previous example.
within the page-bean-class:
so you don't have to repeat all annotations of the domain-class within the page-bean.
within the domain-class:
within the page-bean-class:
so you don't have to repeat all annotations of the domain-class within the page-bean.
within the domain-class:
Friday, April 4, 2008
sev-en preview - first public demo
i uploaded the intermediate result of the sev-en demo at:
http://people.apache.org/~gpetracek/myfaces/extval/
http://people.apache.org/~gpetracek/myfaces/extval/
Wednesday, April 2, 2008
sev-en preview - a short example
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.
using sev-en:
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.
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.
using sev-en:
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.
Monday, March 31, 2008
7 - my new jsf extension
today i presented the first preview of sev-en.
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.
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.
boot sequence finished successfully
initialize new blog...
boot sequence finished ................... [ok]
the open source blog of gerhard petracek
established successfully ................. [ok]
yes - yet another blog :)
boot sequence finished ................... [ok]
the open source blog of gerhard petracek
established successfully ................. [ok]
yes - yet another blog :)
Subscribe to:
Posts (Atom)