Re: [hibernate-dev] HV-376
Answers inline.
Gunnar
2011/2/7 Emmanuel Bernard <emmanuel(a)hibernate.org>
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
I find the idea of BeanDescriptor extending TypeDescriptor pretty good as
this actually reflects reality, a bean is a special kind of type. So for BV
1.1 we might have this:
TypeDescriptor extends ElementDescriptor {
boolean isTypeConstrained();
Set<MethodDescriptor> getConstrainedMethods();
MethodDescriptor getConstraintsForMethod(Method method);
}
public interface BeanDescriptor extends TypeDescriptor {
boolean isBeanConstrained();
PropertyDescriptor getConstraintsForProperty(String propertyName);
Set<PropertyDescriptor> getConstrainedProperties();
}
There would be no notion of the property concept on TypeDescriptor.
BeanDescriptor would be compatible with BV 1.0. One could retrieve
TypeDescriptors for arbitrary types, BeanDescriptors for bean types, just as
now. So BeanDescriptor would be some sort of "view" at a type focused on
bean properties. Calling getConstrainedMethods() on a BeanDescriptor would
return the annotated getter methods, in case there are any. Calling
getConstrainedProperties() for a type which has no bean style properties
would return nothing. BeanDescriptor#isBeanConstrained() would return false
if a type only has method level constraints.
For HV 4.2 we could also do the following:
TypeDescriptor extends ElementDescriptor {
boolean isTypeConstrained();
Set<MethodDescriptor> getConstrainedMethods();
MethodDescriptor getConstraintsForMethod(Method method);
getBeanDescriptor();
}
So one could get the BD from a TD if needed and this would be inline with
the above approach for BV 1.1 as there is no inheritance relation we have to
revert later. WDYT?
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?
I don't see a real case for this either. Just wanted to make sure we all
agree on this :-)
BTW
MethodDescriptor#getMethod
why is it required? I think we've discussed that but I forgot.
You would need it if you called TypeDescriptor#getConstrainedMethods().
Then you would have a Set<MethodDescriptor> with descriptors for any of the
methods and couldn't tell for which method they are without getMethod(). It
corresponds with PropertyDescriptor#getName() from my point of view.