nine years ago i implemented ExtValMessageInterpolatorAdapter. back then it allowed to combine the MessageInterpolator (bv) and the MessageResolver (extval). with that it was easy to load violation-messages from a custom message-source. it was needed because there was no agreement in the eg about it. from my first presentation about bv (in 2009) until now i always hear the same (valid) feedback (that there is a gap). the result (back then) was BVAL-217, but besides that nothing changed. four years ago there was the last (official) extval-release. the main reason was that most projects limited themselves to std. bv, because jsf as well as some component libs filled the most important gaps. years later there are still extval features which aren't part of the spec. (message-resolving is just one of them). as a "replacement" projects drop the corresponding requirement/s, use weird workarounds, "copy" parts of frameworks like extval or they moved away from bv and/or jsf anyway.
recently i was asked if it is possible to load bv-violation-messages from a database. furthermore, it would be beneficial to re-use custom concepts for type-safe messages. in such cases apache codi and later on deltaspike helped a lot to benefit from (or implement) such features easily. however, adding such frameworks isn't always an option (although they would help a lot) and in some cases there are still some limits.
so i extracted some parts from extval, codi and deltaspike and combined it with new ideas.
without type-safe messages available with deltaspike, i usually use something like the following pragmatic approach for type-safe messages:
that's easy to use, refactor and it's even possible to create an extension which autom. detects all enums implementing that interface and check for message-id clashes. however, when it comes to bean-validation we have the issue that we can't reference the message-id in a type-safe manner (due to the limited capability of java-annotations in combination with the fact that bv specifies that the message-attribute of constraint-annotations needs to be a string).
to allow at least one enum-type per bv-constraint we can benefit from the composite-constraint feature which is available since v1.0. with that we can define e.g.:
furthermore, in some cases it's useful to use information about the property in the violation message. in the listing above it's realized with the constraint-attribute propertyLabel. with std. bv you can hardcode that info. the main issue here is that there is no i18n support for the constraint-attribute value. instead of (manually) post-processing the violation-messages, it would be better to use the std. key-syntax to reference a different value in the message-source.
to summarize it, we would like e.g. to store the violation-text:
The length of '{propertyLabel}' should be between '{min}' and '{max}'
in a database, create a custom enum which implements a custom interface like MessageId and optionally (type-safe) labels which support i18n (the label-texts are stored in message-sources as well).
for the property-label we also create the corresponding entries in the database.
using those parts with @Length would e.g. look like:
and the resulting message is e.g.:
The length of 'Surname' should be between '2' and '50'
the propertyLabel attribute can be a string following the std. key-format to support i18n.
alternatively it can be also a custom enum (implementing a custom interface). it isn't the same, but similar to the type-safe message-enum itself. due to the autom. interpolation the label-enum needs to be slightly different - e.g.:
the (custom) LabelId interface is just used to distinguish labels from the message itself. since the label is a constraint-attribute it gets interpolated by bv itself and therefore we need to force the key-format to identify the parts which need to be resolved in an own step.
to realize all that you just need to add the ds-bv-label-addon e.g. by adding https://rawgit.com/os890/ds-bv-label-addon/public as maven-repository and afterwards the maven-dependency as well as the custom message-interpolator:
to resolve violation-messages e.g. from a database you can add one or more beans like:
if you like to use message- and/or label-enums you can implement one or more beans like:
the git-repository illustrates different use-cases including one which shows how to share one constraint between different modules without using a shared message-enum (but still keep the type-safe approach) by using a shared composite-constraint in combination with a composite-constraint per module (which delegate to the shared composite-constraint).
Showing posts with label bean-validation. Show all posts
Showing posts with label bean-validation. Show all posts
Friday, June 22, 2018
Thursday, August 8, 2013
apache wink meets bean-validation
today i did my first commit at apache-wink. it's the first draft of the bean-validation integration as specified in the jax-rs 2.0 specification.
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).
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.
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).
Monday, August 2, 2010
[benchmark] myfaces extval
after some performance improvements (see EXTVAL-80) i created a benchmark for the bean-validation (jsr-303) integration module for extval r3 and r4m3. as you know the results depend on a lot of parameters. anyway, the following chart should give you a first impression about the performance improvements. on my system i can reproduce the results (tolerance: ~2 ms). the benchmark invokes the validation for a component 1000 times. the value-binding points to a property which hosts one bv-constraint. the benchmark was started 3 times and the chart shows the rounded average of 10 validations (just because it's more interesting than the validation of 1000 ui components).
furthermore, the chart shows the impact of 2 optimizations described in a first draft for advanced extval/bv topics. optimization #1 just deregisters the validation interceptor which allows to create any kind of custom annotations for jsf validation (it's the base implementation of the property-validation module). optimization #2 deregisters the implementation of EXTVAL-83 - one of the new features available in r4+.
furthermore, the chart shows the impact of 2 optimizations described in a first draft for advanced extval/bv topics. optimization #1 just deregisters the validation interceptor which allows to create any kind of custom annotations for jsf validation (it's the base implementation of the property-validation module). optimization #2 deregisters the implementation of EXTVAL-83 - one of the new features available in r4+.
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.
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.
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)
Friday, March 5, 2010
[add-on] spring 3 managed constraint validation for extval
there is a new add-on which allows using typesafe spring 3 dependency injection for constraint validators. so it's possible to inject other beans (e.g. a validation service, a repository,...) into a constraint validator.
it's similar to the native extval di support. the main difference is that the add-on offers a typesafe alternative. you just have to extend the default-implementation (listed at @Constraint(validatedBy = {...})) and provide the custom implementation as spring bean.
it's similar to the native extval di support. the main difference is that the add-on offers a typesafe alternative. you just have to extend the default-implementation (listed at @Constraint(validatedBy = {...})) and provide the custom implementation as spring bean.
Thursday, December 17, 2009
metadata based validation @ejug seminar (german)
the slides of the metadata based validation presentation at the ejug seminar in linz.
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
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/
Subscribe to:
Posts (Atom)