recently i created an example for tomee.
its origin is an example which used the same java-ee parts you find in tomee out-of-the-box, but configured manually for a servlet container like tomcat. the biggest change i had to do was to drop most dependencies. i just had to keep myfaces codi and extval. besides adding org.apache.openejb:javaee-api as provided dependency, i also added org.apache.openejb.maven:tomee-maven-plugin to start tomee and deploy the example with:
mvn tomee:run.
in the code i could keep everything as it was (the cleanup i did wasn't a required step to get it up and running with tomee). in case of the config i just had to drop some parts in web.xml and persistence.xml.
the rest worked immediately!
Showing posts with label extval. Show all posts
Showing posts with label extval. Show all posts
Wednesday, May 1, 2013
Thursday, December 22, 2011
5th release of myfaces-extensions-validator
The Apache MyFaces team is pleased to announce the 5th release of Apache MyFaces Extensions Validator (aka ExtVal).
Labels:
bean-validation,
extval,
jsf,
jsr 303,
myfaces-extval,
sev-en
Saturday, August 27, 2011
[myfaces] setup of codi and extval
in the last weeks i saw a lot of users looking for information about setting up and/or configuring extval and/or codi.
the simple answer: both don't required configuration by default.
zero config allows you to add the jar files you would like to use to your project and that's it.
(in case of codi you have to ensure that you have configured the cdi implementation of your choice correctly. in case of the bv module of extval, you have to ensure that you added the bv implementation of your choice.)
information about the libs is available in the corresponding wiki which is liked on the official website of each project. please check the wiki and/or send a mail to the mailing list.
the simple answer: both don't required configuration by default.
zero config allows you to add the jar files you would like to use to your project and that's it.
(in case of codi you have to ensure that you have configured the cdi implementation of your choice correctly. in case of the bv module of extval, you have to ensure that you added the bv implementation of your choice.)
information about the libs is available in the corresponding wiki which is liked on the official website of each project. please check the wiki and/or send a mail to the mailing list.
Labels:
codi,
config,
extval,
myfaces,
myfaces codi,
myfaces-extval
Sunday, November 28, 2010
myfaces extval release news r3 -> r4
these slides give a short overview of the most important new features of the 4th release of myfaces extval.
Labels:
bean-validation,
extval,
jsf,
jsr 303,
myfaces-extval,
sev-en
Saturday, November 27, 2010
4th release of myfaces-extensions-validator
The Apache MyFaces team is pleased to announce the 4th release of Apache MyFaces Extensions Validator (aka ExtVal).
Labels:
bean-validation,
extval,
jsf,
jsr 303,
myfaces-extval,
sev-en
Thursday, November 11, 2010
[infra] myfaces extensions meet dvcs
it's getting easier for the community to contribute to myfaces-extensions *!
now we have official git mirrors:
and
as well as inofficial mercurial mirrors (hg isn't supported by the asf):
and
in case of myfaces-extensions * the mercurial repositories provide an additional feature. early adaptors can request an inofficial (external) milestone at any time. it's easier to handle issues compared to nightly builds.
dvcs like mercurial and git allow easy forking of repositories and experimenting with new features. with features like squash it's very easy to donate the result of your feature-branch!
so let's get started: fork -> experiment -> donate (your patch)!
Labels:
codi,
extcdi,
extval,
git,
hg,
mercurial,
myfaces,
myfaces codi,
myfaces-extensions,
myfaces-extval
Friday, September 24, 2010
[javaone] myfaces extval and myfaces codi meet j1 2010
that's nice! matthias and ali presented myfaces at j1 2010. one part of the presentation was myfaces extval (e.g. [1] [2]) and a second part was about myfaces codi (e.g. [1] [2]). it was the first preview of myfaces codi at a java conference.
Labels:
codi,
extcdi,
extval,
javaone,
myfaces,
myfaces codi,
myfaces-extensions,
myfaces-extval
Tuesday, June 1, 2010
multi-field form validation with jsr 303
there is a new extval add-on (new location). this first draft of the add-on allows so called multi-field (or cross-field) validation based on jsr 303.
within the page you just use normal input components - e.g.:

furthermore, you annotate e.g. your page bean with @FormValidator. the annotation also allows to specify a specific view-id, conditions as well as validation groups. to implement a more fine-grained multi-validation it's possible to provide multiple form-bean classes. to implement more complex combinations it's possible to use @FormValidator.List(...). (as alternative you can also us the provided java api to map your bean(s) to a form-validator. so if you don't like to use the annotation you can provide a separated mapping.)
usage of @FormValidator:

in the page you see the id's of the different components. we have to use these id's as field-names (or setter-methods) in the form-validator.
the following figure shows a possible form-validator for this example:

as soon as the form-validator-bean is annotated with @Form, the validator is called by the bean-validation engine. so the violation message gets processed by the bean-validation engine and the final message is added as global faces-message.
(if you would like to use the current ConstraintValidatorContext of bean-validation, you can directly implement the FormBean interface instead of extending ViolationMessageAwareFormBean.)
if you use e.g. input components within a data-table, you can use 'add'-methods instead of the setter-method. in the form-validator you can use a data-structure like a list per column. as soon as the validation process starts (at the end of the validation phase) the form-validator contains all values (in case of input components in tables the validator is aware of all table values). so it's possible to implement any multi-field validation you can imagine (in case of input components in tables also validations per row as well as across rows).
additional features:
it's possible to map the form-bean-class to specific view-id's, to provide conditions as well as validation groups.
within the page you just use normal input components - e.g.:

furthermore, you annotate e.g. your page bean with @FormValidator. the annotation also allows to specify a specific view-id, conditions as well as validation groups. to implement a more fine-grained multi-validation it's possible to provide multiple form-bean classes. to implement more complex combinations it's possible to use @FormValidator.List(...). (as alternative you can also us the provided java api to map your bean(s) to a form-validator. so if you don't like to use the annotation you can provide a separated mapping.)
usage of @FormValidator:

in the page you see the id's of the different components. we have to use these id's as field-names (or setter-methods) in the form-validator.
the following figure shows a possible form-validator for this example:

as soon as the form-validator-bean is annotated with @Form, the validator is called by the bean-validation engine. so the violation message gets processed by the bean-validation engine and the final message is added as global faces-message.
(if you would like to use the current ConstraintValidatorContext of bean-validation, you can directly implement the FormBean interface instead of extending ViolationMessageAwareFormBean.)
if you use e.g. input components within a data-table, you can use 'add'-methods instead of the setter-method. in the form-validator you can use a data-structure like a list per column. as soon as the validation process starts (at the end of the validation phase) the form-validator contains all values (in case of input components in tables the validator is aware of all table values). so it's possible to implement any multi-field validation you can imagine (in case of input components in tables also validations per row as well as across rows).
additional features:
it's possible to map the form-bean-class to specific view-id's, to provide conditions as well as validation groups.
Labels:
bean-validation,
extval,
extval-add-on,
jsf,
jsr 303,
sev-en,
validation,
validator
Friday, April 9, 2010
extval meets cwiki.apache.org
today i created a new cwiki-space for extval.
within the next weeks i'll move and improve the documentation of extval.
you are welcome to ask questions in order to improve the content!
within the next weeks i'll move and improve the documentation of extval.
you are welcome to ask questions in order to improve the content!
Labels:
extval,
jsf,
myfaces-extensions,
myfaces-extval,
sev-en
Friday, March 26, 2010
extval meets paper
bart kummel wrote a book about the myfaces project.
i'll publish a review about the book quite soon.
it also contains an intro of myfaces extval!
it's really great that the extval chapter is the free sample chapter.
so enjoy reading it!
i'll publish a review about the book quite soon.
it also contains an intro of myfaces extval!
it's really great that the extval chapter is the free sample chapter.
so enjoy reading it!
Thursday, March 25, 2010
extval r3 in action - fullstack 2010
this fullstack demo illustrates some use-cases of using jsf 1.2, spring 3, myfaces extval r3, bean-validation,... in case of myfaces extval the demo also shows how to keep all layers outside the view-layer independent of extval classes. so you see how to re-use existing (extval independent) constraints for ui validation in a typesafe way.
furthermore, the demo shows how to integrate bean-validation (jsr 303) in jsf 1.x applications.
further details are available in the (short) readme file.
here is the list of the used technologies:
- jsf 1.2 (+ facelets)
- myfaces orchestra
- myfaces extval r3 (+ some add-ons)
- bean-validation (jsr 303)
- spring 3
- jpa 1.0
- primefaces
furthermore, the demo shows how to integrate bean-validation (jsr 303) in jsf 1.x applications.
further details are available in the (short) readme file.
here is the list of the used technologies:
- jsf 1.2 (+ facelets)
- myfaces orchestra
- myfaces extval r3 (+ some add-ons)
- bean-validation (jsr 303)
- spring 3
- jpa 1.0
- primefaces
Wednesday, March 24, 2010
myfaces extval release news r2 -> r3
these slides give a short overview of the most important features of the 3rd release of myfaces extval.
Labels:
bean-validation,
extval,
jsf,
jsr 303,
myfaces-extval,
sev-en
3rd release of myfaces-extensions-validator
the apache myfaces team is pleased to announce a new release of myfaces-extensions-validator!
the release contains several improvements and new features as well as a new validation module for using bean-validation (jsr 303) with jsf 1.x and 2.0.
(compared to the standard integration of bv in jsf 2.0 extval 2.0.3 offers more advanced and typesafe features.)
released versions:
extval 1.1.3 (for jsf 1.1.x)
extval 1.2.3 (for jsf 1.2.x)
extval 2.0.3 (for jsf 2.0.x)
the release contains several improvements and new features as well as a new validation module for using bean-validation (jsr 303) with jsf 1.x and 2.0.
(compared to the standard integration of bv in jsf 2.0 extval 2.0.3 offers more advanced and typesafe features.)
released versions:
extval 1.1.3 (for jsf 1.1.x)
extval 1.2.3 (for jsf 1.2.x)
extval 2.0.3 (for jsf 2.0.x)
Labels:
bean-validation,
extval,
jsf,
jsr 303,
myfaces-extval,
sev-en
Thursday, December 17, 2009
metadata based validation @ejug seminar (german)
the slides of the metadata based validation presentation at the ejug seminar in linz.
Labels:
bean-validation,
ejug,
extval,
jsf,
jsr 303,
validation,
validator
Subscribe to:
Posts (Atom)