Re: [hibernate-dev] HV-376
Hi,
On 6 févr. 2011, at 20:57, Gunnar Morling wrote:
one other issue we might/should deliver for Beta2 is
http://opensource.atlassian.com/projects/hibernate/browse/HV-371 ("Support
method-level constraints in meta-data API"), at least API-wise. I pushed a first
draft to https://github.com/gunnarmorling/hibernate-validator/tree/HV-371 and would be
happy on your feedback.
With some exceptions this is pretty similar to what is suggested in Appendix C. As we
can't alter the BeanDescriptor type, I created a new type TypeDescriptor (I think the
name is better anyways, as constraints are no longer restricted to bean-style types with
the advent of method validation). This type resembles BeanDescriptor (it doesn't
inherit for the naming reason but I would let me convince if you think it should) and is
returned by MethodValidator#getConstraintsForType().
It seems that in the grand scheme of BV 1.1, we would put all your methods back on
BeanDescription without necessarily adding a new type. I initially thought of adding
TypeDescriptor as a superclass of BeanDescriptor but the idea of having the noting of
properties on TypeDescriptor felt wrong (in Java).
WDYT?
If we all agree then that means TypeDescriptor is really a (temporary) subclass of
BeanDescriptor
Anything else is pretty much straight forward. Currently it is not possible to determine
from which exact method version in a hierarchy a certain constraint originates (using the
ConstraintFinder API one can only find out, whether a constraint is defined locally or
*somewhere* up in the hierarchy). Do you think this would be needed? I think, the same
restriction holds for the existing property descriptor API.
I've always envisioned that one in need to find where a constraint was exactly would
use a combination of lookingAt(LOCAL_ELEMENT) and clazz.getSuperclass().
What would be the use case for reaching the exact method straight?
The existing methods (getElementClass(), getConstraintDescriptors() etc.) on
ElementDescriptor all seem to make sense for the new descriptor types. For
MethodDescriptor they should relate to the return value type/constraints, for
ParameterDescriptor to the parameter type/constraints.
yep.
WDYT, should we ship this as API in Beta2 for public review and implement it with the
next milestone? I'm also CC-ing Emmanuel as I think he originally wrote Appendix C.
Fine by me, it's up to you guys. The design is very much inline with the original
design of Bean Validation.
BTW
MethodDescriptor#getMethod
why is it required? I think we've discussed that but I forgot.