[hibernate-dev] On possible extensions for the validator

Federico Mancini mancini_federico at yahoo.it
Wed Oct 6 11:53:38 EDT 2010


  Hi,
I just wanted to make a remark on the the difference between the class 
level validation
in the jsr 303 and our cross-annotations, since I would like to hear 
your opinion on the matter (that you probably have already discussed).

Class level validation is something we had considered as well, but 
discarded it as we considered it in a way "cheating" in our settings.
This because what actually happens, if I understood correctly, is that 
the whole object is passed to the validator, at which point it is 
possible to create
a validator class that has access to all properties of the object to 
validate and therefore check any kind of interdependent  constraints.
This however at cost of reusability and flexibility, since such class 
level annotations can only be used on that specific class, and this 
could easily be replaced
by an internal method in the object to validate, which can be called at 
validation time. So we didn't see the clear advantage of annotations in 
this case.
Still, this makes sense in a bigger framework like Hibernate, where one 
would like to have also more complicated validation and it is nice to 
have only one consistent way of
defining constraints.

What we mean with cross-annotations is something much weaker. Only the 
values of the properties annotated with the same cross-annotation are 
passed to the validator,
as a list, so that the validator does not know which value comes from 
which property.
The disadvantage is that the set of properties to validate can only be 
seen as a list of values, and what can be checked is that a certain 
amount of them satisfies the contraint.
Of course if the values have each different a type, one might cheat and 
still know what is what up to a certain extent (similarly to a class 
level validation).
The advantage (which was our priority), is that normal validation 
annotations (on single fields and methods) can be reused and composed 
also to create cross-annotations,
remaining independet of the class, and requiring to write less code.

Hence we can say that cross annotations are a compromise between class 
level validation and normal property validation.

So the question is: would  cross-annotations still be interesting in a 
validator where we have class level validation, or would it be only 
redundant?

A simple case in which I think cross-annotations might come in handy, 
is, for instance, when there is a set of properties where at least one 
of them must be non-null, but not necessary all of them
(like multiple choice questionnaire).
This would very simply be:

@CrossProperty(operator=PropertyOperator.ATLEAST, n=1)
@NotNull \\normal property annotation
public @interface ExactlyOneNull {}

Federico


Den 05.10.2010 15:17, skrev Hardy Ferentschik:
> Hi Frederico,
>
> sorry for the late reply. I finally had some time to read through your 
> paper.
> I think there are strong similarities between you work and Hibernate 
> Validator or
> more specific the Bean Validation specification (JSR 303).
>
> Property validation in the SHIP Validator is basically the same as in 
> Bean Validation.
> And what you call cross-annotations would be a class level validator 
> in Bean Validation terms.
>
> Bean Validation also offers constraint composition similar to what is 
> described in your paper.
> What Bean Validation does not offer is a boolean composition of the 
> constraints. Here conjunction of
> constraints is always assumed.
>
> We are not able to do something like this:
>
>
> @BoolTest(BoolType.OR)
> @Null
> @Max(10)
> @Target({ METHOD, FIELD })
> @Retention(RUNTIME)
> @Constraint(validatedBy = { })
> public @interface NullOrMax {
>    public abstract String message() default "foo";
>    public abstract Class<?>[] groups() default { };
>    public abstract Class<? extends Payload>[] payload() default { };
>    @OverridesAttribute(constraint = Max.class, name = "value")
>    public abstract long max()
> }
>
> Also the ability to validate a subset of all properties from within a 
> class level validator sounds interesting.
>
> We could implement these features as Hibernate Validator specific 
> extensions.
> Are you interested in getting involved?
>
>
> --Hardy
>
>
> On Tue, 05 Oct 2010 09:48:15 +0200, Federico Mancini 
> <mancini_federico at yahoo.it> wrote:
>
>>   Hi again,
>> I was just wondering whether I should interpret the lack of answers as
>> "no, this is not interesting at all", or as "we have a lot of other
>> things to do and do not have time for this right now"?
>>
>> Federico
>>
>> Den 22.09.2010 09:08, skrev Federico Mancini:
>>>    Hi all,
>>> I am new to the list and I am opening this thread on Emmanuel Bernard's
>>> suggestion, in order to
>>> discuss some possible extensions to the validator (jsr 303) I have been
>>> working on with a couple of collegues.
>>> Mainly it concerns the possibility to extend composition with boolean
>>> operators (ex.: A field is either in the range 1-10 OR 20-30 AND
>>> notNull)  and allow validation of sets of interdependent properties
>>> (ex.: EITHER the name field is notNull OR the surname field is notNull/
>>> AT LEAST 1 field must be filled/etc....).
>>>
>>> A description of the experimental framework we implemented can be found
>>> here http://www.ii.uib.no/publikasjoner/texrap/pdf/2009-389.pdf , and
>>> some further discussion on the choices we made here
>>> http://www.ii.uib.no/~federico/papers/Annotations.pdf.
>>>
>>> I hope this might be of some interest for the Hybernate Validator 
>>> project,
>>> but, even if not, it would be nice to get some feedback.
>>>
>>> Thanks,
>>> Federico Mancini
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>




More information about the hibernate-dev mailing list