[
http://opensource.atlassian.com/projects/hibernate/browse/HV-549?page=com...
]
Hardy Ferentschik commented on HV-549:
--------------------------------------
Hi,
to be honest, I don't fully understand what you are proposing and why. I guess you are
not talking about _validte_ and _validateAllParameters_, but rather _validateProperty_ and
_validateParameter_.
{quote}
ValidatorImpl currently supports methods for validating bean properties / method
parameters. Looking from the outside, I don't see a strong reason for using bean
properties / method parameters other than that these elements are annotation
placeholders.
{quote}
The properties are not just placeholders. They are abstractions. The idea behind Bean
Validation is to be _Bean_ (object) centric and hence you provide property paths. In your
case you pass the constraints to validate via an array of annotations. How do you
determine this array? You would have to process the bean yourself and consider things like
inheritance and implemented interfaces yourself. Why not letting the bean validation
framework taking care of this? Also, annotations seems to be the wrong abstraction either
way. What's about XML configuration or the programmatic configuration?
Do you have any convincing usecase for your suggestion?
add method ValidatorImpl.validateElement(Annotation[],
Class<?>, Type, Object value, Class<?>... groups)
--------------------------------------------------------------------------------------------------------
Key: HV-549
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HV-549
Project: Hibernate Validator
Issue Type: New Feature
Reporter: George Sapountzis
ValidatorImpl currently supports methods for validating bean properties / method
parameters. Looking from the outside, I don't see a strong reason for using bean
properties / method parameters other than that these elements are annotation
placeholders.
Using TypeLiteral/AnnotationLiteral helper classes it seems possible to construct all the
necessary metadata for a validation point programmatically. So, I propose to add a generic
method where the annotations/type are passed by the user. The passed value need not be a
bean, it could be a *primitive* value. The resulting set of constraint violations will
just have a null root bean / method.
Hope you consider this a valid case and add such a method, or advise on an alternative
way to achieve the same functionality. I'd like to do this without writing straw
beans/methods and introspecting them just for the sake of adapting to the API. I am not
able to find my way around to achieving this currently.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira