On 8 févr. 2011, at 09:20, Gunnar Morling wrote:
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.
Let me summarize:
- BD extends TD
- BD#getConstrainedMethod() returns constraints getters and methods (*)
- BD#isBeanConstrained() does not change contract
(*) it's the logical approach but I feel like it might be inconvenient.
An alternative approach to alleviate (*) is to consider BeanDescriptor as a view as you
said:
- TD extends ElementDescriptor
- BD extends ElementDescriptor
- you can access BD from TD ( getBeanDescriptor() )
For HV 4.2 we could also do the following:
TypeDescriptor extends ElementDescriptor {
boolean isTypeConstrained();
Set<MethodDescriptor> getConstrainedMethods();
MethodDescriptor getConstraintsForMethod(Method method);
getBeanDescriptor();
}
ahahah, well we had the same idea.