Hi,
I would really love the type-safe interface and removing the classcast
handling from implementations,
totally agree with that proposal.
I am not liking the flexibility to have several different
implementations associated to the same annotation;
IMHO using a 1-1 should be more clear to the user which validation
implementation he is going to use.
The "check String length" "check Array size" and "check Collection
size" validators could use different annotations;
by the same criteria it would be fine for Collection, Map and Set to
share the same annotation to check for
size, as the implementation is only concerned about receiving a
Collection as common superinterface.
I can live with some more annotations if it is more explicit to
understand which one is going to be used,
especially if the validation framework warns me about incompatible
types at startup.
(and developers wouldn't need to consider mystic
AmbiguousValidatorException implications).
If there is need for it, the "Resolution algorithm" looks like ok but
IMHO you can spare yourself that complexity.
Sanne
2009/1/23 Emmanuel Bernard <emman...@hibernate.org>:
> Today, ConstraintValidator accepts Object and the implementation is
> responsible for handling the casting and raise an exception if the type is
> not supported.
> The idea is to get type-safe validator and a discovery mechanism to
> associate a validator to a given runtime type being validated. The
> resolution is not 100% complete, you might end up with:
> - no valid validator
> - no way to decide between two or more validators
> and get exceptions at runtime.
> I would really like feedback on it as we could arrange some of these rules
> to not fail (at least in the latter case):
> - do we want this type-safe + auto resolution algorithm strategy or should
> we stick with the untyped solution
> - do we want to fail in case of ambiguity or rather choose the first
> compatible provider?
> Personally I find the feature quite elegant and the metadata can be used by
> tools to warn a user if a constraint does not match the static type it is
> applied on.
> API and declaration
>
> A more typesafe proposal would be:
> public interface ConstraintValidator<A extends Annotation, T> {
> void initialize(A annotation);
> boolean isValid(T object, ConstraintValidationContext context);
> }
> public class StringSizeValidator implements ConstraintValidator<Size,
> String> {
> ...
> }
> public class CollectionSizeValidator implements ConstraintValidator<Size,
> Collection> {
> ...
> }
> public class MapSizeValidator implements ConstraintValidator<Size, Map> {
> ...
> }
> public class ArraySizeValidator implements ConstraintValidator<Size,
> Object[]> {
> ...
> }
>
> @Constraint(validatedBy={
> StringSizeValidator.class, CollectionSizeValidator.class,
> MapSizeValidator.class, ArraySizeValidator.class} )
> public @interface Size { ... }
> We then need to decide at runtime, which validator needs to be executed.
> Here is a proposed algorithm heavily based on the Java Language
> Specification (boy it's hard to read it).
> Resolution algorithm
> The type T of a ConstraintValidator must not make direct use of generics
> itself.
> This is because the algorithm compare the actual type at runtime and such
> notion would be lost. So you can do ConstraintValidator<Size, Collection>
> but not ConstraintValidator<Size, Collection<String>>.
> For a given runtime object t of type T about to be validated for a given
> constraint:
> if t is null the first validator in the array of available validators is
> used.
> otherwise
> A validator accepting U is said to be compliant with the type T if T is a
> subtype of U according to the JLS chapter 4.10.
> If no compliant validator is found for T, a UnexpectedTypeForConstraint
> exception is raised.
> If a validator is taking the responsibility to dispatch types (ie
> ConstraintValidator<Size,Object>), it must use the same exception in the
> same circumstances.
> If one compliant validator is found, it is used.
> If more than one compliant validator is found, the one with the most
> specific parameter is used. The informal intuition is that one parameter is
> more specific than another if any assignment handled by the first parameter
> could be passed on to the other one without a compile-time type error.
> Of a given type T, a compliant validator accepting U is considered maximally
> specific if no other T compliant validator accepting V is such as V is a
> strict subtype of U. String subtype is defined by JSL chapter 4.10.
> If more than one maximally specific validator is found, a
> AmbiguousValidatorException is raised.
> WDYT?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
