[hibernate-dev] On possible extensions for the validator

[Federico Mancini]

  Yes, I completely agree, I didn't mean to suggest to actually replace 
the annotations with internal code, but only that in this case the 
advantage
of using annotations is reduced to the simple decoupling of validation 
code form the rest, as it can be obtained with an XML configuration 
file. All the other advantages like composition and
reusability are lost. With cross-annotation instead, one could still 
have everything at cost of less expressive power.

However what I was most interested in, was exactly to understand whether 
the loss in re-usability was worth the full control in writing 
validation tests.
So, once you tell me this is acceptable, I have to agree the the added 
complexity of implementing cross-annotations might not be worth having
one more type of annotations which can make it easier to write only a 
limited type of "multiple" validation tests.

Federico

P.S.: you cannot indeed distinguish cross-annotations from the rest in 
the code. The only thing I can think about to solve this, would be to
create a predefined group to which all cross-annotations should belong 
(since they are anyway validated separatly from the rest) , and write 
the group esplicitely
when the annotation is used in the code (but still, it would be easier 
to make suh a group the default group for the annotation at declaration 
time, which would re-create the problem).


Den 11.10.2010 12:01, skrev Hardy Ferentschik:


> On Wed, 06 Oct 2010 17:53:38 +0200, Federico Mancini 
> <mancini_federico at yahoo.it> wrote:
>
>> 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.
>
> Once you are going down this road you start breaking the idea of 
> making validation
> an orthogonal concern. The idea is to separate validation from other
> business logic. Using specific methods in the object itself introduces
> dependencies between your code and the validation framework.

>> 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.
>
> Your cross-annotation support should also be possible using Bean 
> Validation,
> a class level validator for the type Object and some reflection code.
>
>> 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.
>
> I think in most usecases users prefer to write class specific 
> validators which give
> them full control what and how to validate. This might come at the 
> costs of
> some re-usability, but that's acceptable in this case.
>
>> 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?
>
> Not sure if it is worth the added complexity. Another concern is that 
> purely by looking
> at the validation annotations you don't know that you are having a 
> property or
> a cross annotation constraint.
>
>
> --Hardy
>