[hibernate-dev] HV-376

[Emmanuel Bernard]

On 8 févr. 2011, at 09:20, Gunnar Morling wrote:
> 
> 2011/2/7 Emmanuel Bernard <emmanuel at 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.