the next part of the article series is available at jsfcentral.
thx to the jsfcentral team!
Thursday, December 17, 2009
metadata based validation @ejug seminar (german)
the slides of the metadata based validation presentation at the ejug seminar in linz.
Saturday, December 12, 2009
happy birthday myfaces-extval
one year ago we saw the first release of myfaces extensions validator.
the second release was a small but powerful update.
the third release will be available soon. it is a major update and will provide a lot new great features as well as a new validation module which allows to use bean-validation (jsr 303) with all jsf versions as well as some other additional features compared to the standard integration of bv in jsf 2. the latest milestone is available at the snapshot repository. it's already very stable and you can start using it right now! (currently we are in the review phase - so you can already use the current milestone until the version gets released.)
so extval and its add-ons will continue to help you to solve your daily validation tasks with powerful and easy to use mechanisms.
within the last year i received a lot of great feedback as well as a lot ideas for great add-ons. over 17 000 page-hits (in ~100 different countries) within the first year is really great for such an extension! these numbers are just for os890. if you also count the articles, wikis,... it's much higher!
so all of you are welcome to use the current milestone and don't stop to provide feedback as well as ideas for great new features and improvements...
the second release was a small but powerful update.
the third release will be available soon. it is a major update and will provide a lot new great features as well as a new validation module which allows to use bean-validation (jsr 303) with all jsf versions as well as some other additional features compared to the standard integration of bv in jsf 2. the latest milestone is available at the snapshot repository. it's already very stable and you can start using it right now! (currently we are in the review phase - so you can already use the current milestone until the version gets released.)
so extval and its add-ons will continue to help you to solve your daily validation tasks with powerful and easy to use mechanisms.
within the last year i received a lot of great feedback as well as a lot ideas for great add-ons. over 17 000 page-hits (in ~100 different countries) within the first year is really great for such an extension! these numbers are just for os890. if you also count the articles, wikis,... it's much higher!
so all of you are welcome to use the current milestone and don't stop to provide feedback as well as ideas for great new features and improvements...
Thursday, November 26, 2009
primefaces and jsr 303 via extval
the previous post shows how easy it is to set-up extval to be used with primefaces.
in the meantime i created a small example [1] which shows that it is very easy to use jsr 303 constraints in a primefaces application via extval.
furthermore, the demo shows ajax validation based on jpa annotations as well as cross-validation via ajax and the none-blocking warn mode.
moreover, the example shows the optional component support module for primefaces. for example it allows component initialization of the password-component based on meta-data. that's equivalent to the functionally available for the standard components. if a property bound to this special primefaces component hosts meta-data about min and max length (e.g. the jsr 303 constraint @Size(min = 7, max = 14), these information get transferred to the component automatically.
a sample screen of the demo:
[1] http://code.google.com/p/sandbox890/source/browse/#svn/trunk/examples/primefaces_extval/example_01
in the meantime i created a small example [1] which shows that it is very easy to use jsr 303 constraints in a primefaces application via extval.
furthermore, the demo shows ajax validation based on jpa annotations as well as cross-validation via ajax and the none-blocking warn mode.
moreover, the example shows the optional component support module for primefaces. for example it allows component initialization of the password-component based on meta-data. that's equivalent to the functionally available for the standard components. if a property bound to this special primefaces component hosts meta-data about min and max length (e.g. the jsr 303 constraint @Size(min = 7, max = 14), these information get transferred to the component automatically.
a sample screen of the demo:
[1] http://code.google.com/p/sandbox890/source/browse/#svn/trunk/examples/primefaces_extval/example_01
Monday, November 23, 2009
os890 maven repository
it was a frequent user request that the myfaces-extval add-ons should be available via a maven 2 repository. so i created a repository for os890 as well as for sandbox890.
so you just have to add e.g. the following part to the repositories section of your pom.xml
snapshots are available via
further information are available in the usage-wiki as well as the repository overview!
so you just have to add e.g. the following part to the repositories section of your pom.xml
<repository>
<id>os890.googlecode.com</id>
<url>http://os890-m2-repository.googlecode.com/svn/tags/os890</url>
</repository>
snapshots are available via
<repository>
<id>os890.googlecode.com</id>
<url>http://os890-m2-repository.googlecode.com/svn/trunk/os890</url>
</repository>
further information are available in the usage-wiki as well as the repository overview!
Sunday, November 15, 2009
myfaces extval 2 and icefaces 2
today i had a quick look at the first version of icefaces 2. it looks really nice. so i added extval to the component demo project.
i tested simple constraints as well as cross-validation (cross-component-validation/inter component validation). both worked quite nice also with ajax enabled input components.
also new extval features like severity aware validation (e.g. non-blocking warn mode) work quite well.
i'm looking forward to seeing the final version!
the upgrade of the demo (with extval) was done quite fast:
just adding the jar files and using the constraints!
in this case i used the following maven dependencies for extval:
groupId: org.apache.myfaces.extensions.validator
artifactId: myfaces-extval-core
version: 2.0.3-SNAPSHOT
groupId: org.apache.myfaces.extensions.validator.validation-modules
artifactId: myfaces-extval-property-validation
version: 2.0.3-SNAPSHOT
currently we also need (we will see if we need it with the final version as well)
groupId: org.apache.myfaces.extensions.validator.component-support-modules
artifactId: myfaces-extval-generic-support
version: 2.0.3-SNAPSHOT
for sure also the myfaces extval support for jsr 303 works out-of-the-box after adding the needed jar files...
Friday, November 13, 2009
bean-validation constraint validators and dependency injection support in jsf
myfaces extval allows to use beans as validators. so it's possible to inject services into validators. bean-validation (jsr 303) specifies that the class of a validator has to be defined hardcoded. anyway, via the ConstraintValidatorFactory it's possible to change the default behavior.
in jsf you can query beans by name (not by type which is possible e.g. in spring). extval allows to provide a custom implementation of the ValidatorFactory. so you can optimize the lookup for your dependency management container (e.g. to make it typesafe).
anyway, out of the box the bv-integration module of extval (the next milestone of it) allows to provide/override constraint-validators via bean(s).
a detailed description is available at EXTVAL-70.
a spring bean for the example mentioned in EXTVAL-70 would be:
<bean id="customConstraintValidator"> class="at.gp.demo.CustomConstraintValidator" scope="prototype"> <property name="customService" ref="..."></bean>
Thursday, November 12, 2009
bean-validation support for richfaces via extval
today i upgraded an internal richfaces 3.3.x demo to use extval to integrate jsr 303 validation.
the upgrade was done quite fast:
just adding the jar files and using the bv constraints!
in this case i used the following maven dependencies:
for richfaces:
groupId: org.richfaces.ui
artifactId: richfaces-ui
version: 3.3.2.GA
for extval:
groupId: org.apache.myfaces.extensions.validator
artifactId: myfaces-extval-core
version: 1.2.3-SNAPSHOT
required to use a4j with extval:
groupId: org.apache.myfaces.extensions.validator.component-support-modules
artifactId: myfaces-extval-generic-support
version: 1.2.3-SNAPSHOT
to use jsr 303 validation:
groupId: org.apache.myfaces.extensions.validator.validation-modules
artifactId: myfaces-extval-bean-validation
version: 1.2.3-SNAPSHOT
groupId: org.hibernate
artifactId: hibernate-validator
version: 4.0.0.GA
groupId: org.slf4j
artifactId: slf4j-api
version: 1.4.2
groupId:org.slf4j
artifactId: slf4j-log4j12
version: 1.4.2
to support org.richfaces.component.html.HtmlCalendar
groupId: sandbox890.extensions.validator.component-support-modules
artifactId: myfaces-extval-richfaces-support
from http://code.google.com/p/sandbox890/
Friday, October 23, 2009
[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)
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)
Monday, October 12, 2009
[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:
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:
Sunday, September 27, 2009
myfaces-extval MetaDataStorageFilter and @JoinValidation
beside some other improvements a new concept will be available with the next milestone.
a generic storage concept is used to cache the basic meta-data.
all mechanisms which allow dynamic meta-data remain the same. instead of caching the final meta-data for a property just the basic meta-data gets cached. the meta-data which is extracted from the original property. as an addition to the existing dynamic meta-data mechanisms a new concept is available. in comparison to a MetaDataExtractionInterceptor the new MetaDataStorageFilter is just invoked before meta-data gets added to the storage.
it's an additional extension point which allows you e.g. to introduce new functionality which isn't available out of the box.
the property-validation module of extval uses such a filter to introduce a new syntax for @JoinValidation. so it's possible to use a static syntax instead of the dynamic possibilities.
some nice syntax examples are available at one of the example classes.
so maybe you ask - MetaDataStorageFilter are fine but all i need is already possible via a MetaDataExtractionInterceptor. why do i need such filters? yes that's right, however, the new filter concept in combination with the meta-data-storage allow a better performance.
MetaDataExtractionInterceptor ... use them if you have to decide to add/remove/change meta-data very dynamically - e.g. based on the current program-flow, app-state,...
MetaDataStorageFilter ... use them if you would like to introduce a custom but static concept and benefit from the better performance
a generic storage concept is used to cache the basic meta-data.
all mechanisms which allow dynamic meta-data remain the same. instead of caching the final meta-data for a property just the basic meta-data gets cached. the meta-data which is extracted from the original property. as an addition to the existing dynamic meta-data mechanisms a new concept is available. in comparison to a MetaDataExtractionInterceptor the new MetaDataStorageFilter is just invoked before meta-data gets added to the storage.
it's an additional extension point which allows you e.g. to introduce new functionality which isn't available out of the box.
the property-validation module of extval uses such a filter to introduce a new syntax for @JoinValidation. so it's possible to use a static syntax instead of the dynamic possibilities.
some nice syntax examples are available at one of the example classes.so maybe you ask - MetaDataStorageFilter are fine but all i need is already possible via a MetaDataExtractionInterceptor. why do i need such filters? yes that's right, however, the new filter concept in combination with the meta-data-storage allow a better performance.
MetaDataExtractionInterceptor ... use them if you have to decide to add/remove/change meta-data very dynamically - e.g. based on the current program-flow, app-state,...
MetaDataStorageFilter ... use them if you would like to introduce a custom but static concept and benefit from the better performance
Saturday, September 12, 2009
myfaces-extval-add-on - app-prototyping - 3
since the original functionality was promoted and will be part of the next version. i added a new functionality. it might be the case that you have issues while prototyping. if so, please report them to the mailing list. anyway, normally you would have to remove extval from the classpath so that you can continue your work. that's due to the zero config approach of extval. you can deactivate it via api's but now you have a further possibility.
the current trunk version (= the next milestone) allows to provide a custom implementation of the extval-context. that allows to introduce alternative approaches e.g. using a dependency injection framework like spring and google guice for internal tasks as well as registering artifacts via dependency injection.
it also allows to mock the extval context. so you can deactivate all/specific features easily. an example is available at [1]. since you have to configure a custom extval-context manually (the class provides the needed information to do it), you can add it to your project permanently. if you would like to check something without extval, just activate the config and afterwards you can remove it again. as mentioned before, it also allows to deactivate specific features easily without using web.xml context-parameters.
anyway, normally you shouldn't have problems. if you find issues, please report them as soon as possible.
[1] http://code.google.com/p/os890/source/browse/trunk/java/web/jsf/extval/prototyping/org/apache/myfaces/extensions/validator/custom/DevExtValContext.java
the current trunk version (= the next milestone) allows to provide a custom implementation of the extval-context. that allows to introduce alternative approaches e.g. using a dependency injection framework like spring and google guice for internal tasks as well as registering artifacts via dependency injection.
it also allows to mock the extval context. so you can deactivate all/specific features easily. an example is available at [1]. since you have to configure a custom extval-context manually (the class provides the needed information to do it), you can add it to your project permanently. if you would like to check something without extval, just activate the config and afterwards you can remove it again. as mentioned before, it also allows to deactivate specific features easily without using web.xml context-parameters.
anyway, normally you shouldn't have problems. if you find issues, please report them as soon as possible.
[1] http://code.google.com/p/os890/source/browse/trunk/java/web/jsf/extval/prototyping/org/apache/myfaces/extensions/validator/custom/DevExtValContext.java
Sunday, September 6, 2009
myfaces-extval java-config extension with gooogle guice style
why you might need this add-on
there are many different approaches to configure myfaces-extval.
out-of-the-box it uses zero configuration (convention over configuration) as well as an optional java-api which is mainly for internal usages and add-on developers.
so os890 provides an annotation based config add-on. so you don't have to learn the name conventions and the result is typesafe.
the disadvantage is that classpath scanning is required. you can specify packages to be scanned. anyway, it uses an external lib which performs the classpath scanning.
that's the reason for creating an additional add-on which is typesafe and doesn't use an external lib. as mentioned before extval provides an api and a generic artifact mapping mechanism which is used mainly for internal purposes. you can see the usage in the source-code of some add-ons. anyway, app-developers who don't like conventions need a simple but powerful api which is available for the common artifacts.
google guice provides a nice api to bundle modules. so the api of the add-on is similar to the style of google guice. that means you build modules and register the modules you would like to use.
the usage
first you implement a module. in a module you register global artifacts or you bind together a validation strategy with one or more of the following artifacts: constraint, message resolver, meta data transformer.
the following example shows both:
you just have to add your global artifacts or bind together artifacts which have a relationship. so you see that the syntax is quite easy.
via an extval startup listener you can register one or more modules easily.
the result
it's typesafe, explicit, flexible without external dependency and easy to use.
it's available at http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/java_based_config
a working example is available at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/examples/basic/demo_010
there are many different approaches to configure myfaces-extval.
out-of-the-box it uses zero configuration (convention over configuration) as well as an optional java-api which is mainly for internal usages and add-on developers.
so os890 provides an annotation based config add-on. so you don't have to learn the name conventions and the result is typesafe.
the disadvantage is that classpath scanning is required. you can specify packages to be scanned. anyway, it uses an external lib which performs the classpath scanning.
that's the reason for creating an additional add-on which is typesafe and doesn't use an external lib. as mentioned before extval provides an api and a generic artifact mapping mechanism which is used mainly for internal purposes. you can see the usage in the source-code of some add-ons. anyway, app-developers who don't like conventions need a simple but powerful api which is available for the common artifacts.
google guice provides a nice api to bundle modules. so the api of the add-on is similar to the style of google guice. that means you build modules and register the modules you would like to use.
the usage
first you implement a module. in a module you register global artifacts or you bind together a validation strategy with one or more of the following artifacts: constraint, message resolver, meta data transformer.
the following example shows both:
you just have to add your global artifacts or bind together artifacts which have a relationship. so you see that the syntax is quite easy.
via an extval startup listener you can register one or more modules easily.
the resultit's typesafe, explicit, flexible without external dependency and easy to use.
it's available at http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/java_based_config
a working example is available at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/examples/basic/demo_010
Thursday, July 30, 2009
myfaces-extval-add-on - app-prototyping - 2
due to a valid user request (a possible combination with spring security) also the functionality of the extval app-prototyping add-on (and more) will be available in the next release. early adaptors can use the current svn version or the next milestone (m2) which will be available soon.
the add-on won't be obsolete. there will be new functionality!
the add-on won't be obsolete. there will be new functionality!
Wednesday, July 29, 2009
myfaces extval @ jsfcentral
the next part of the article series is available at jsfcentral.
thx to the jsfcentral team!
thx to the jsfcentral team!
Tuesday, July 21, 2009
myfaces-extval and pattern based validation
i saw that people search quite often for an example which shows pattern/regex based validation.
it's quite easy. just use @Pattern and use the regex as value (as expected).
a short example is:
@Pattern("[A-Z][a-z]+")
the examples shipped with every extval release shows the usage as well.
or you can check out the examples from the repository.
it's quite easy. just use @Pattern and use the regex as value (as expected).
a short example is:
@Pattern("[A-Z][a-z]+")
the examples shipped with every extval release shows the usage as well.
or you can check out the examples from the repository.
Saturday, July 18, 2009
myfaces extval and richfaces - 2
i started a special support module for richfaces.
currently it contains an addition to support labeled faces messages for the rich:calendar component.
currently it contains an addition to support labeled faces messages for the rich:calendar component.
myfaces-extval and icefaces - 2
this is an update of the original post:
1)
extval and icefaces uses similar approaches to implement an internal mechanism. with mojarra there is no issue (by chance). in combination with myfaces-core there was an issue which is fixed with the following combination: icefaces 1.8.2 (see ) and an icefaces support module.
2)
internally icefaces components use some jsf 1.1 mechanisms. that's the reason why you have to use the described fallback. that will change with icefaces 2.0 (which will be compatible with jsf 1.2).
if you are using the support module + the current extval-snapshot + the upcoming version of icefaces (1.8.2 - or a pached version of 1.8.1), you don't have to follow the instructions of the original post. you just have to add the dependencies and everything will work as expected.
a very simple example is available here
1)
extval and icefaces uses similar approaches to implement an internal mechanism. with mojarra there is no issue (by chance). in combination with myfaces-core there was an issue which is fixed with the following combination: icefaces 1.8.2 (see ) and an icefaces support module.
2)
internally icefaces components use some jsf 1.1 mechanisms. that's the reason why you have to use the described fallback. that will change with icefaces 2.0 (which will be compatible with jsf 1.2).
if you are using the support module + the current extval-snapshot + the upcoming version of icefaces (1.8.2 - or a pached version of 1.8.1), you don't have to follow the instructions of the original post. you just have to add the dependencies and everything will work as expected.
a very simple example is available here
myfaces extval - new snapshot available
early adaptors can use the current snapshot!
it includes some minor internal changes as well as EXTVAL-49 - EXTVAL-53.
furthermore, it's the version used for component-support/icefaces-support
it includes some minor internal changes as well as EXTVAL-49 - EXTVAL-53.
furthermore, it's the version used for component-support/icefaces-support
Wednesday, July 15, 2009
os890 thanks for the great interest
it's amazing. today i had a look at the google analytics statistics.
since the first announcement of myfaces extval a lot people evaluated the framework, provided ideas for add-ons and new features, sent several e-mails about the great experience while using extval and much more.
half a year ago we saw the first release of extval.
now i can report some nice numbers of os890:
~4000 visitors
~12000 page views
and visitors of 88 countries
furthermore, within 5 months there were over 900 downloads of the introduction slides.
these numbers don't include the statistics of the wiki pages hosted at apache directly.
since the first announcement of myfaces extval a lot people evaluated the framework, provided ideas for add-ons and new features, sent several e-mails about the great experience while using extval and much more.
half a year ago we saw the first release of extval.
now i can report some nice numbers of os890:
~4000 visitors
~12000 page views
and visitors of 88 countries
furthermore, within 5 months there were over 900 downloads of the introduction slides.
these numbers don't include the statistics of the wiki pages hosted at apache directly.
your custom cross-validation
if you have a bunch of cross-validation strategies, please have a look at EXTVAL-53!
in case of objections, please send a veto to undo the change.
so far there wasn't a major change which affects custom implementations. this is the first one. we did it to stay consistent internally and because it is very easy to migrate with a simple search/replace action which is safe.
if you just used the annotations, you won't notice a change. you just notice it at custom cross-validation implementations. normally there aren't tones of it, so it isn't a big issue. nevertheless backward compatibility is basically important for us. since it's an important change for some of you, everybody is allowed to veto.
details are available the description of the issue.
in case of objections, please send a veto to undo the change.
so far there wasn't a major change which affects custom implementations. this is the first one. we did it to stay consistent internally and because it is very easy to migrate with a simple search/replace action which is safe.
if you just used the annotations, you won't notice a change. you just notice it at custom cross-validation implementations. normally there aren't tones of it, so it isn't a big issue. nevertheless backward compatibility is basically important for us. since it's an important change for some of you, everybody is allowed to veto.
details are available the description of the issue.
Friday, July 10, 2009
Wednesday, July 8, 2009
myfaces extval snapshots
several people asked for a new version via a public maven repository.
in fact the current snapshot contains some great new features. so extval for jsf 1.2.x is now available in the snapshot repository!
(the next release of extval depends e.g. on the final release of jsr303 - so i plan stable snapshots for important milestones. feel free to use the latest snapshot!)
in fact the current snapshot contains some great new features. so extval for jsf 1.2.x is now available in the snapshot repository!
(the next release of extval depends e.g. on the final release of jsr303 - so i plan stable snapshots for important milestones. feel free to use the latest snapshot!)
Monday, July 6, 2009
myfaces extval and richfaces
so far this combination worked when using myfaces-core.
extval-38 (as well as the wiki) shows the required dependencies.
the mentioned issue describes that there is an issue with mojarra.
the good news: the issue is fixed and you can use this combination.
i hope a lot of you (who signaled interest in this combination) will start to test the new version or a patched version of v1.2.2 you can find here.
some details about the original issue:
the generic support module is required, if a component lib does special things behind the scenes.
e.g.: casting renderers,...
so the module uses cglib to allow that. via an extval startup listener the module installs itself. the issue with mojarra is that it uses early configuration. so the extval startup listener of the module gets invoked too late and important configuration tasks are performed by an extval-core class instead of the lazily installed class of the generic support module.
extval-38 (as well as the wiki) shows the required dependencies.
the mentioned issue describes that there is an issue with mojarra.
the good news: the issue is fixed and you can use this combination.
i hope a lot of you (who signaled interest in this combination) will start to test the new version or a patched version of v1.2.2 you can find here.
some details about the original issue:
the generic support module is required, if a component lib does special things behind the scenes.
e.g.: casting renderers,...
so the module uses cglib to allow that. via an extval startup listener the module installs itself. the issue with mojarra is that it uses early configuration. so the extval startup listener of the module gets invoked too late and important configuration tasks are performed by an extval-core class instead of the lazily installed class of the generic support module.
Wednesday, June 24, 2009
myfaces extval and seam
you might have looked at my first comparison of extval and the seam 2.x integration of hibernate validator [1]. some of you were interested in a seam support of extval to get the best of both frameworks.
i've tested extval with seam and it worked quite well. to use extval also with richfaces the generic-support module of extval is required. some weeks ago the test with myfaces core was successful. there is just an issue with the combination of (richfaces + extval + mojarra). if you would like to use this combination, feel free to look into the issue and provide some details and/or a patch to fix it.
furthermore, it's possible to use both solutions in parallel.
i've tested extval with seam and it worked quite well. to use extval also with richfaces the generic-support module of extval is required. some weeks ago the test with myfaces core was successful. there is just an issue with the combination of (richfaces + extval + mojarra). if you would like to use this combination, feel free to look into the issue and provide some details and/or a patch to fix it.
furthermore, it's possible to use both solutions in parallel.
Sunday, June 21, 2009
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!
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!
Saturday, June 20, 2009
myfaces-extval-add-on - transactional model validation light
this add-on is a prototype for lightweight transactional model validation.
it also offers basic support for class-level validation.
to mention it once again:
normally extval performs all (simple- as well as cross-) constraint-validations within the validation phase of jsf. however, sometimes it's required to validate after the model was updated. e.g. class-level validations, tree validations,...
to allow these validations this add-on triggers the validation process after the model was updated. furthermore, the original model values of the processed properties (before the model updated) are restored, if there is a violation during model aware and/or class level validation.
in comparison to the full transactional model validation prototype, this add-on doesn't require cglib or spring.
attention: other changes e.g. executed by value-change-listeners,... don't get reverted
1) class level constraints are validated automatically
this mechanism shouldn't be an alternative to jsr 303 - it's just a simple implementation to illustrate the possibility of such a validation. (you are free to implement your own solution based on this mechanism as custom-add-on). moreover, there will be also a similar add-on for jsr 303 class-level validation.
2) a constraint aspect allows a fine-grained definition of constraints which should get validated after the model was updated.
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/examples/advanced/demo_111
shows a simple example.
some details:
that means:
#1 there are constraints which get validated in the validation phase (as usual)
#2 there are constraints (see ModelAwareValidation.class) which get validated after the model was updated
#3 there are class-level-constraints (see the custom @Vehicle constraint)
the pages don't contain validation logic as usual with extval.
so - let's test the application with invalid values:
this means: validation mentioned of #1 happened
this means: within the validation phase only a constraint of first-name was violated -> the other constraints aren't violated or they should be validated after the model update which isn't performed due to a violation in the validation phase.
this means: only constraints of the model-aware-validation are violated - so you see messages you haven't seen so far.
so far we haven't looked at the transactional validation behavior of the add-on.
the described invalid tries lead to the following behavior behind the scenes:
try #1 and #2:
no model update
try #3 leads to:
model update:
setFirstName: Gerhard
setLastName: P
setManufacturer: MyCar
setModelIdentification: MyCar
violation during model aware and (/or) class-level validation:
-> revert new model values
setFirstName: null
setLastName: null
setManufacturer: null
setModelIdentification: null
in this case null was the last valid model value of all properties (since we haven't had values in the model).
you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/transactional_model_validation_light
it also offers basic support for class-level validation.
to mention it once again:
normally extval performs all (simple- as well as cross-) constraint-validations within the validation phase of jsf. however, sometimes it's required to validate after the model was updated. e.g. class-level validations, tree validations,...
to allow these validations this add-on triggers the validation process after the model was updated. furthermore, the original model values of the processed properties (before the model updated) are restored, if there is a violation during model aware and/or class level validation.
in comparison to the full transactional model validation prototype, this add-on doesn't require cglib or spring.
attention: other changes e.g. executed by value-change-listeners,... don't get reverted
1) class level constraints are validated automatically
this mechanism shouldn't be an alternative to jsr 303 - it's just a simple implementation to illustrate the possibility of such a validation. (you are free to implement your own solution based on this mechanism as custom-add-on). moreover, there will be also a similar add-on for jsr 303 class-level validation.
2) a constraint aspect allows a fine-grained definition of constraints which should get validated after the model was updated.
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/examples/advanced/demo_111
shows a simple example.
some details:
that means:
#1 there are constraints which get validated in the validation phase (as usual)
#2 there are constraints (see ModelAwareValidation.class) which get validated after the model was updated
#3 there are class-level-constraints (see the custom @Vehicle constraint)
the pages don't contain validation logic as usual with extval.
so - let's test the application with invalid values:
this means: validation mentioned of #1 happened
this means: within the validation phase only a constraint of first-name was violated -> the other constraints aren't violated or they should be validated after the model update which isn't performed due to a violation in the validation phase.
this means: only constraints of the model-aware-validation are violated - so you see messages you haven't seen so far.so far we haven't looked at the transactional validation behavior of the add-on.
the described invalid tries lead to the following behavior behind the scenes:
try #1 and #2:
no model update
try #3 leads to:
model update:
setFirstName: Gerhard
setLastName: P
setManufacturer: MyCar
setModelIdentification: MyCar
violation during model aware and (/or) class-level validation:
-> revert new model values
setFirstName: null
setLastName: null
setManufacturer: null
setModelIdentification: null
in this case null was the last valid model value of all properties (since we haven't had values in the model).
you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/transactional_model_validation_light
Friday, June 12, 2009
myfaces-extval-add-on - advanced metadata
this add-on is a collection of some metadata add-ons. you can still use the other add-ons independently. anyway, this collection allows some internal improvements and you don't have to care about possible side-effects. it just works.
currently the add-on combines:
- metadata provider
- virtual metadata
- conditional metadata exclusion
- metadata priority
the combined usage at your properties (of all included add-ons) looks like:
the separation is of course optional - since it's a feature of one of the add-ons, it's used in this example.
you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/advanced_metadata
currently the add-on combines:
- metadata provider
- virtual metadata
- conditional metadata exclusion
- metadata priority
the combined usage at your properties (of all included add-ons) looks like:
the separation is of course optional - since it's a feature of one of the add-ons, it's used in this example.
you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/advanced_metadata
myfaces-extval-add-on - conditional metadata exclusion
extval allows to include and exclude metadata dynamically. currently there are already a lot add-ons out there. this add-on allows to exclude metadata conditionally in a fine-grained manner. furthermore, it's possible to use it for 3rd party annotations as well.
the usage at your properties looks like:
if you have multiple target conditions the usage looks like:
you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/conditional_metadata_exclusion
the usage at your properties looks like:
if you have multiple target conditions the usage looks like:
you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/conditional_metadata_exclusion
myfaces-extval-add-on - virtual metadata
maybe you thought - extval supports 3rd party annotations (e.g. jpa based validation) and the new typesafe constraint aspects aren't available for 3rd party constraints.
the virtual metadata add-on solves this restriction.
the usage at your properties looks like:
you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/virtual_metadata
the virtual metadata add-on solves this restriction.
the usage at your properties looks like:
you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/virtual_metadata
Thursday, June 11, 2009
myfaces-extval-add-on - metadata priority
this add-on allows to force a validation priority (independent of the used order).
it's especially useful for the metadata-provider add-on. so you can prioritize the found constraints. anyway, it isn't bound to the other add-on - so you can use it independently.
(or impl. your own add-on - it's quite simple)
simple example:
you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/metadata_priority
it's especially useful for the metadata-provider add-on. so you can prioritize the found constraints. anyway, it isn't bound to the other add-on - so you can use it independently.
(or impl. your own add-on - it's quite simple)
simple example:
you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/metadata_priority
Tuesday, June 9, 2009
myfaces-extval-add-on - metadata provider
this time don't look at the images before your have read the text. it's really important to understand the special use-cases!
basically this add-on shows how to add constraints from an alternative source to the current validation-process. it's possible since extval 1.x.2 via a custom MetaDataExtractionInterceptor. this add-on uses special java-classes as alternative source. however, you can use e.g. xml files,... as alternative source. it's up to you - the way you have to do it is more or less the same.
one idea of metadata based validation is that you have the constraints where they belong to. jsr 303 will allow to define cross-layer constraints (by definition). extval allows the same. anyway, if you have view-layer centric constraints e.g. the out-of-the-box available extval constraints (just the dependency itself is view-layer specific) and your architecture doesn't allow to use them in your entities, you have ~5 choices:
1) only use the jsr 303 support of extval x.x.3+
disadvantage: less features (due to jsr 303 itself)!!!
2) implement your own set of constraints:
advantage: they have no dependency to extval - but you can use extval to validate them in jsf applications. since they don't depend on extval, you can use your own validation engine in the other layers or ... (too much possibilities for this post)
disadvantage: you have to implement, test, maintain,... them
3) use the metadata-provider add-on (or impl. a similar one)
advantage: use existing constraints outside your entities and bind it to the entities in a typesafe manner...
disadvantage: depends on your opinion
4) change your architecture
normally that isn't a real option.
5) don't use extval
do you think that it is a nice option for your jsf-application? i don't think so ;)
you still read this entry - so you are interested in the approach of the add-on :)
just to mention it again - extval allows to validate any constraints. that's a base principle. extval introduces no requirement to your constraints. you can also provide validators for your existing constraints... so you can use constraints which have no (in-/)direct dependency to extval. that's a base principle! but maybe you have special constraints just for your view-layer or you have to bind your fields against existing implementations or you are using something like dto's or ... . this add-on solves possible architecture issues you might have had so far and demonstrates alternative constraint sources in general.
your entity:
the decoupled style via name convention:
the convention is: place it in the same package + the MetaData postfix.
possible issues after refactoring of your application:
- property names of the entity might change (-> use the extends * approach of the following style)
- the class name/location might change (-> you need the 2nd approach)
-> to solve both there is an alternative approach:
the typesafe version:
... you extend the target (entity) and override the properties which are the targets for the ui-specific constraints. the add-on uses scannotation to discover such classes. so you can use any package and class-name. if you refactor the person class e.g. lastName -> surName your ide should automatically rename the overridden properties as well (at least @Override helps you to detect errors). so it's a really typesafe approach. (you have to provide the target class as value of @MetaDataProvider - this might change in the final version)
optionally you can use:
ExtValContext.getContext().addGlobalProperty(
MetaDataProviderStorage.KEY, "your package");
within an extval startup-listener to define a custom package to scan.
in your application you add extval, the add-on and your metadata provider classes to your jsf application. if you have other modules for the other layers, they aren't affected!
so if the only argument against extval/constraint based validation was that you aren't allowed to use the out-of-the-box annotations or ..., you see how the solution could look like (or just use it). and be happy, if you don't have such requirements and you can just use extval as it is :)
you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/metadata_provider
basically this add-on shows how to add constraints from an alternative source to the current validation-process. it's possible since extval 1.x.2 via a custom MetaDataExtractionInterceptor. this add-on uses special java-classes as alternative source. however, you can use e.g. xml files,... as alternative source. it's up to you - the way you have to do it is more or less the same.
one idea of metadata based validation is that you have the constraints where they belong to. jsr 303 will allow to define cross-layer constraints (by definition). extval allows the same. anyway, if you have view-layer centric constraints e.g. the out-of-the-box available extval constraints (just the dependency itself is view-layer specific) and your architecture doesn't allow to use them in your entities, you have ~5 choices:
1) only use the jsr 303 support of extval x.x.3+
disadvantage: less features (due to jsr 303 itself)!!!
2) implement your own set of constraints:
advantage: they have no dependency to extval - but you can use extval to validate them in jsf applications. since they don't depend on extval, you can use your own validation engine in the other layers or ... (too much possibilities for this post)
disadvantage: you have to implement, test, maintain,... them
3) use the metadata-provider add-on (or impl. a similar one)
advantage: use existing constraints outside your entities and bind it to the entities in a typesafe manner...
disadvantage: depends on your opinion
4) change your architecture
normally that isn't a real option.
5) don't use extval
do you think that it is a nice option for your jsf-application? i don't think so ;)
you still read this entry - so you are interested in the approach of the add-on :)
just to mention it again - extval allows to validate any constraints. that's a base principle. extval introduces no requirement to your constraints. you can also provide validators for your existing constraints... so you can use constraints which have no (in-/)direct dependency to extval. that's a base principle! but maybe you have special constraints just for your view-layer or you have to bind your fields against existing implementations or you are using something like dto's or ... . this add-on solves possible architecture issues you might have had so far and demonstrates alternative constraint sources in general.
your entity:
the decoupled style via name convention:
the convention is: place it in the same package + the MetaData postfix.possible issues after refactoring of your application:
- property names of the entity might change (-> use the extends * approach of the following style)
- the class name/location might change (-> you need the 2nd approach)
-> to solve both there is an alternative approach:
the typesafe version:
... you extend the target (entity) and override the properties which are the targets for the ui-specific constraints. the add-on uses scannotation to discover such classes. so you can use any package and class-name. if you refactor the person class e.g. lastName -> surName your ide should automatically rename the overridden properties as well (at least @Override helps you to detect errors). so it's a really typesafe approach. (you have to provide the target class as value of @MetaDataProvider - this might change in the final version)optionally you can use:
ExtValContext.getContext().addGlobalProperty(
MetaDataProviderStorage.KEY, "your package");
within an extval startup-listener to define a custom package to scan.
in your application you add extval, the add-on and your metadata provider classes to your jsf application. if you have other modules for the other layers, they aren't affected!
so if the only argument against extval/constraint based validation was that you aren't allowed to use the out-of-the-box annotations or ..., you see how the solution could look like (or just use it). and be happy, if you don't have such requirements and you can just use extval as it is :)
you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/metadata_provider
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.
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
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
@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.
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:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/prototyping
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:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/prototyping
Sunday, April 26, 2009
myfaces extval release news 1.x.1 -> 1.x.2
these slides give a short overview of the new myfaces extval v1.x.2 features.
Monday, April 20, 2009
release of myfaces-extensions-validator
the apache myfaces team is pleased to announce a new release of myfaces-extensions-validator!
released versions:
extval 1.1.2 (for jsf 1.1.x)
extval 1.2.2 (for jsf 1.2.x)
Wednesday, April 15, 2009
[updated] myfaces-extval config extension
extval 1.x.2 provides some new mechanisms. therefore the annotation based config also provides some new annotations.
new annotations:
- MetaDataExtractionInterceptor
- NameMapper
- FacesMessageFactory
extval allows name mappers for different areas. @NameMapper makes it easy to provide a custom name mapping strategies. the following screenshot shows an example how to use @NameMapper
new annotations:
- MetaDataExtractionInterceptor
- NameMapper
- FacesMessageFactory
extval allows name mappers for different areas. @NameMapper makes it easy to provide a custom name mapping strategies. the following screenshot shows an example how to use @NameMapper
myfaces-extval-add-on - @SecuredAction
you might already know that you can use myfaces extval for much more than validation. this new add-on shows how simple it is to provide add-ons for different problem domains. it's available at http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/secure_actions.
@SecuredAction is an annotation to secure the execution of action methods. it's independent of the concrete command component and offers several features. normally you can secure such actions via the rendered attribute. however, maybe you would like to restrict method execution based on new model values (which were updated at the same request). there are several other use-cases where you can use it instead of the required attribute of the command component. at least it is a feasibility study for further extval add-ons.
the base idea is similar to the @RolesAllowed of tobago. this extval-add-on offers a bit more than a role check. if you are just interested in the same functionality without using tobago, it's quite easy to add an "allowedRoles"-attribute as well. it isn't implemented out-of-the-box, because the existing approach of permittedIf-conditions is much more generic.
@SecuredAction offers several features - here are some short examples:
that means:
if one of the condition(s) returns false the "deny"-method is called instead of the annotated method. also the optional return-value is used as expected. so you can execute custom logic in case of denied access.
the following example shows a shorter syntax for the "deny"-method. it's possible to refer a local method directly:
it's also possible to overrule the outcome. the following example forces to redisplay the same page instead of displaying a different one:
furthermore, in case of denied access, you can automatically add a (global) error message via:
the add-on automatically looks at the same package of the class (which hosts the secured action method(s)). the name of the resource bundle is: securty_messages. it's just for demo cases. for real word usages you can register e.g. an existing bundle within an extval-startup listener. you can register a message-bundle base-name or for jsf 1.2+ also a message-bundle var-name.
sample:
//use an existing message bundle
ExtValContext.getContext().addGlobalProperty(
SecuredAction.MESSAGE_BUNDLE, "at.gp.demos.messages.my_messages");
//use an existing message bundle var-name
ExtValContext.getContext().addGlobalProperty(
SecuredAction.MESSAGE_BUNDLE, "#{myMessages}");
in the message bundle you have to add a summary and detail message - e.g.:
action_not_allowed = action not allowed
action_not_allowed_detail = action not allowed - please switch the role
the default case is that @SecuredAction doesn't change the lifecycle execution. via an additional attribute it's possible to change that. the following example always leads to an execution (of the secureAction) in the "apply requests values"-phase. if it's permitted to call the secured method, the original lifecycle execution also doesn't change in this case.
it's also possible to define specific pages which need a secured action method:
to define different scenarios, it's possible to use multiple annotations at one method. you can do that via:
@SecuredAction is an annotation to secure the execution of action methods. it's independent of the concrete command component and offers several features. normally you can secure such actions via the rendered attribute. however, maybe you would like to restrict method execution based on new model values (which were updated at the same request). there are several other use-cases where you can use it instead of the required attribute of the command component. at least it is a feasibility study for further extval add-ons.
the base idea is similar to the @RolesAllowed of tobago. this extval-add-on offers a bit more than a role check. if you are just interested in the same functionality without using tobago, it's quite easy to add an "allowedRoles"-attribute as well. it isn't implemented out-of-the-box, because the existing approach of permittedIf-conditions is much more generic.
@SecuredAction offers several features - here are some short examples:
that means:
if one of the condition(s) returns false the "deny"-method is called instead of the annotated method. also the optional return-value is used as expected. so you can execute custom logic in case of denied access.
the following example shows a shorter syntax for the "deny"-method. it's possible to refer a local method directly:
it's also possible to overrule the outcome. the following example forces to redisplay the same page instead of displaying a different one:
furthermore, in case of denied access, you can automatically add a (global) error message via:
the add-on automatically looks at the same package of the class (which hosts the secured action method(s)). the name of the resource bundle is: securty_messages. it's just for demo cases. for real word usages you can register e.g. an existing bundle within an extval-startup listener. you can register a message-bundle base-name or for jsf 1.2+ also a message-bundle var-name.
sample:
//use an existing message bundle
ExtValContext.getContext().addGlobalProperty(
SecuredAction.MESSAGE_BUNDLE, "at.gp.demos.messages.my_messages");
//use an existing message bundle var-name
ExtValContext.getContext().addGlobalProperty(
SecuredAction.MESSAGE_BUNDLE, "#{myMessages}");
in the message bundle you have to add a summary and detail message - e.g.:
action_not_allowed = action not allowed
action_not_allowed_detail = action not allowed - please switch the role
the default case is that @SecuredAction doesn't change the lifecycle execution. via an additional attribute it's possible to change that. the following example always leads to an execution (of the secureAction) in the "apply requests values"-phase. if it's permitted to call the secured method, the original lifecycle execution also doesn't change in this case.
it's also possible to define specific pages which need a secured action method:
to define different scenarios, it's possible to use multiple annotations at one method. you can do that via:
Tuesday, April 7, 2009
myfaces-extval and prime faces
today i tested extval in combination with primefaces. it worked without modifications. i just added:
- myfaces-extval-core
- myfaces-extval-property-validation
- myfaces-extval-core
- myfaces-extval-property-validation
Thursday, April 2, 2009
myfaces-extval for highlighting validated fields without additional/special components
you can find a short demo case for highlighting validated fields without additional/special components at example 105
the result looks like:
the result looks like:
Tuesday, March 31, 2009
myfaces-extval-add-on - @BypassValidationController
the bypass validation add-on for extval was updated!
beyond the action-method based bypass it's possible to bypass validation with an annotation which is similar to a view-controller annotation. anyway, it works the opposite way round. if the annotation is used validation is bypassed.
you can use the annotation on the first bean (= page/backing bean), the first property (of the page/backing bean), the last base object (owner of the property) and the bound property.
that means something like:
#{pageBean.bean1.bean2.person.firstName}
the green parts are possible targets for @BypassValidationController
a simple example:
that leads to:
1) bypassed extval-validation for every property bound via: #{personPage2. ...}
attention: only skipable validations are bypassed by default. so e.g. jpa based validation continues to work. if you would like to really bypass everything, you have to use:
@BypassValidationController(@ViewId(all = true))
instead.
2) bypassed extval-validation for every property bound via: #{personPage2.person ...}
but only for the view-id "/pages/new_person2.xhtml" + the given condition is true.
it's important to mention that the 4 possible targets for @BypassValidationController are optional. e.g. it's possible to annotate a property without annotating the class itself. furthermore, there are useful default values for all attributes.
beyond the action-method based bypass it's possible to bypass validation with an annotation which is similar to a view-controller annotation. anyway, it works the opposite way round. if the annotation is used validation is bypassed.
you can use the annotation on the first bean (= page/backing bean), the first property (of the page/backing bean), the last base object (owner of the property) and the bound property.
that means something like:
#{pageBean.bean1.bean2.person.firstName}
the green parts are possible targets for @BypassValidationController
a simple example:
that leads to:1) bypassed extval-validation for every property bound via: #{personPage2. ...}
attention: only skipable validations are bypassed by default. so e.g. jpa based validation continues to work. if you would like to really bypass everything, you have to use:
@BypassValidationController(@ViewId(all = true))
instead.
2) bypassed extval-validation for every property bound via: #{personPage2.person ...}
but only for the view-id "/pages/new_person2.xhtml" + the given condition is true.
it's important to mention that the 4 possible targets for @BypassValidationController are optional. e.g. it's possible to annotate a property without annotating the class itself. furthermore, there are useful default values for all attributes.
myfaces-extval and icefaces
i did some quick tests with icefaces and extval.
behind the scenes icefaces does some tricks.
so it's required to deactivate 2 extval mechanisms. with this workaround a hello world icesfaces started working with myfaces extval.
#1: deactivate the extval el-resolver via web.xml context-parameter:
org.apache.myfaces.extensions.validator.DEACTIVATE_EL_RESOLVER
true
#2 switch or deactivate the default renderer proxy implementation via a extval-startup-listener.
deactivate it via:
...
protected void init()
{
ExtValContext.getContext().addGlobalProperty(ExtValRendererProxy.KEY, null);
}
...
i haven't tried more complex applications. you are welcome to try it out :)
if you find some issues please report them.
behind the scenes icefaces does some tricks.
so it's required to deactivate 2 extval mechanisms. with this workaround a hello world icesfaces started working with myfaces extval.
#1: deactivate the extval el-resolver via web.xml context-parameter:
#2 switch or deactivate the default renderer proxy implementation via a extval-startup-listener.
deactivate it via:
...
protected void init()
{
ExtValContext.getContext().addGlobalProperty(ExtValRendererProxy.KEY, null);
}
...
i haven't tried more complex applications. you are welcome to try it out :)
if you find some issues please report them.
Thursday, March 5, 2009
myfaces-extval-add-on - @BypassValidation for action methods
there is a new add-on for myfaces-extval.
it's hosted at [1] and a sample application is available at [2].
[intro]
normally you have to validate all bound properties.
extval provides out-of-the-box a skip validation feature.
if one of the expressions of @SkipValidation returns true, validation of skipable validators gets canceled (the validation strategy has to be marked with @SkipValidationSupport).
anyway, sometimes you need actions which aren't immediate but they have to get executed without validation. therefore this add-on provides @BypassValidation
[new]
just add the add-on to your classpath and annotate these special action methods - example:
@BypassValidation
this simple case bypasses all skipable validations, if the annotated action method will be called.
-> e.g.: in this case @Required doesn't get validated whereas db constraints like nullable = false and length are validated in any case. (see the next usage, if you would like to bypass everything. however, please notice that it might lead to an exception if you try to save an invalid entity. so it's better to use all = false)
if you would like to bypass all validations use:
@BypassValidation(all = true)
furthermore, you can provide one or more optional el-expressions.
so it is possible to bypass validation just if one of the conditions returns true.
@BypassValidation(
condition="#{currentUserRole.privileged}")
requirements: myfaces-extval 1.x.2-SNAPSHOT+
[1] http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/bypass_validation
[2] http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/examples/basic/demo_009
it's hosted at [1] and a sample application is available at [2].
[intro]
normally you have to validate all bound properties.
extval provides out-of-the-box a skip validation feature.
if one of the expressions of @SkipValidation returns true, validation of skipable validators gets canceled (the validation strategy has to be marked with @SkipValidationSupport).
anyway, sometimes you need actions which aren't immediate but they have to get executed without validation. therefore this add-on provides @BypassValidation
[new]
just add the add-on to your classpath and annotate these special action methods - example:
@BypassValidation
this simple case bypasses all skipable validations, if the annotated action method will be called.
-> e.g.: in this case @Required doesn't get validated whereas db constraints like nullable = false and length are validated in any case. (see the next usage, if you would like to bypass everything. however, please notice that it might lead to an exception if you try to save an invalid entity. so it's better to use all = false)
if you would like to bypass all validations use:
@BypassValidation(all = true)
furthermore, you can provide one or more optional el-expressions.
so it is possible to bypass validation just if one of the conditions returns true.
@BypassValidation(
condition="#{currentUserRole.privileged}")
requirements: myfaces-extval 1.x.2-SNAPSHOT+
[1] http://code.google.com/p/
[2] http://code.google.com/p/
Monday, February 23, 2009
myfaces-extval vs seam 2.x integration of hibernate validator - a first draft
here you see a first draft of the comparison myfaces-extval vs. the seam 2.x integration of hibernate validator (currently hibernate validator v4 is still alpha. so it isn't compared here).
hibernate validator v4 will be the ri-implementation of jsr 303. myfaces-extval will also provide an integration module to use a jsr 303 implementation with all jsf versions.
it's just a first draft. please don't get me wrong. it shouldn't be a statement against seam or hibernate validator. both frameworks are nice. however, that's how it looks like at the current state. the goal is just to have a correct side-by-side comparison of the available features. so please contact me, if you think that the seam side provides a feature i might have missed so far. i'll correct it.
Thursday, February 12, 2009
principles of myfaces-extval
this picture illustrates the base principles of extval:
- no special requirements for meta-data
- support of existing jsf component libs
- compatible with existing and future java ee standards
- extensible and customizable (custom add-ons)
- no special requirements for meta-data
- support of existing jsf component libs
- compatible with existing and future java ee standards
- extensible and customizable (custom add-ons)
Tuesday, January 27, 2009
myfaces-extval introduction slides
These slides introduce MyFaces Extensions Validator. This first part is a short overview. To get more information about MyFaces Extensions Validator we also offer slides with all important details you need to use and customize MyFaces ExtVal. Do not hesitate to contact us!
Tuesday, January 20, 2009
Saturday, January 17, 2009
myfaces-extval examples available
the os890 project offers several examples [1] which illustrate different myfaces extval features. they also show different approaches to solve common requirements (sometimes multiple approaches per requirement). beside some comments each example contains a README.txt which summarizes the illustrated features of the example. an overview is available at [2].
besides these examples extval itself also provides examples at [3] [4]
[1] http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/examples
[2] http://code.google.com/p/os890/wiki/MyFaces_Extensions_Validator_Example_Overview
[3] http://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/examples/
[4] http://apache.org/dist/myfaces/binaries/
besides these examples extval itself also provides examples at [3] [4]
[1] http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/examples
[2] http://code.google.com/p/os890/wiki/MyFaces_Extensions_Validator_Example_Overview
[3] http://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/examples/
[4] http://apache.org/dist/myfaces/binaries/
Subscribe to:
Posts (Atom)