[hibernate-dev] HV-376

[Gunnar Morling]

Answers inline.

Gunnar


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.

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.