[
http://opensource.atlassian.com/projects/hibernate/browse/BVAL-233?page=c...
]
Emmanuel Bernard updated BVAL-233:
----------------------------------
Description:
I'm using the Hibernate Validators since the day it got released. I wrote some
extensions which also might be useful to other users:
I extended the MessageInterpolator so that I can use the rootBean, leafBean and the
invalidValue in the message templates. Further I added support for nested properties. Here
are some samples for (extended) message templates: - "The age of {leafBean.firstname}
{leafBean.lastname} must be between {min} and {max} but is {invalidValue}." =>
"The age of John Doe must be between 18 and 65 but is 17." - "Error on
{rootBean}: The the transaction's ({leafBean.transactionId}) amount ({invalidValue})
is too low." - "{invalidValue} is not a valid account number." While this
information is unnecessary while you are typing the data and see the whole record, it
might be essential if the input is a file and the message is written to a log.
It would also useful to provide some custom properties in the MessageInterpolator
context:
beanValidator.validateValue(Person.class, "firstName", person.getFirstName); ...
ctx.put("fieldName", "first name");
msgInterpolator.interpolate(constraintViolation.getMessageTemplate(), ctx); - "The
field '{context.fieldName}' must not be empty."
While the leafBean is available as "validatedValue" in the
MessageInterpolator.Context, I had to extend the context to provide the other values.
The validator has only access to the validated object and the annotation. It is not always
possible and reasonable to set the context information on the validated object. It would
be good to have some context available in the validator. Now I pass the context
information through a threadlocal variable which is very ugly and error prone. E.g. a
validator could check if a value is equal to an entry of a dynamic list which depends on
the context.
Sometimes it would be useful to pass some context to the validator:
{code}
validateBean(Object validationContext, T object, Class<?>... groups)
validateProperty(Object validationContext, T object, String propertyName,
Class<?>... groups);
...
public class MyValidator implements javax.validation.ConstraintValidator<MyConstraint,
MyObject> {
public boolean isValid(MyObject myObject, ConstraintValidatorContext context) {
((MyService)
context.getValidatorContext()).doSomeComplexValidation(myObject);
}
{code}
Of course time consuming validation should not be triggered too often. A constaint causing
such a validation would typically not define the Default.class group.
See also:
http://relation.to/Bloggers/JSRBeanVali ... mment19490
Regards René
Provide additional including custom variables for message
interpolation
-----------------------------------------------------------------------
Key: BVAL-233
URL:
http://opensource.atlassian.com/projects/hibernate/browse/BVAL-233
Project: Bean Validation
Issue Type: New Feature
Components: spec-general
Environment: See
https://forum.hibernate.org/viewtopic.php?f=26&t=1011431
Reporter: Emmanuel Bernard
I'm using the Hibernate Validators since the day it got released. I wrote some
extensions which also might be useful to other users:
I extended the MessageInterpolator so that I can use the rootBean, leafBean and the
invalidValue in the message templates. Further I added support for nested properties. Here
are some samples for (extended) message templates: - "The age of {leafBean.firstname}
{leafBean.lastname} must be between {min} and {max} but is {invalidValue}." =>
"The age of John Doe must be between 18 and 65 but is 17." - "Error on
{rootBean}: The the transaction's ({leafBean.transactionId}) amount ({invalidValue})
is too low." - "{invalidValue} is not a valid account number." While this
information is unnecessary while you are typing the data and see the whole record, it
might be essential if the input is a file and the message is written to a log.
It would also useful to provide some custom properties in the MessageInterpolator
context:
beanValidator.validateValue(Person.class, "firstName", person.getFirstName);
... ctx.put("fieldName", "first name");
msgInterpolator.interpolate(constraintViolation.getMessageTemplate(), ctx); - "The
field '{context.fieldName}' must not be empty."
While the leafBean is available as "validatedValue" in the
MessageInterpolator.Context, I had to extend the context to provide the other values.
The validator has only access to the validated object and the annotation. It is not
always possible and reasonable to set the context information on the validated object. It
would be good to have some context available in the validator. Now I pass the context
information through a threadlocal variable which is very ugly and error prone. E.g. a
validator could check if a value is equal to an entry of a dynamic list which depends on
the context.
Sometimes it would be useful to pass some context to the validator:
{code}
validateBean(Object validationContext, T object, Class<?>... groups)
validateProperty(Object validationContext, T object, String propertyName,
Class<?>... groups);
...
public class MyValidator implements javax.validation.ConstraintValidator<MyConstraint,
MyObject> {
public boolean isValid(MyObject myObject, ConstraintValidatorContext context) {
((MyService)
context.getValidatorContext()).doSomeComplexValidation(myObject);
}
{code}
Of course time consuming validation should not be triggered too often. A constaint
causing such a validation would typically not define the Default.class group.
See also:
http://relation.to/Bloggers/JSRBeanVali ... mment19490
Regards René
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira