Den 19.10.2010 10:06, skrev Emmanuel Bernard:
> Cross validation marker annotations like @ExactlyOneNull are not really
> actual constraints (ie annotated with @Constraint) because somehow they must
> carry two logic:
> - the property checking logic
> - the "aggregation" logic
> Besides these markers should be ignored by the rest of the Bean Validation
> execution (they don't mean anything in isolation).
>
> With that in mind I would say that:
> - we should logically forbid BV groups and cross validation groups to reuse
> the same interface to limit confusion. Ideally a different name for the two
> concepts would be better.
> - in practice, they live in different spaces BV constraints host BV groups
> and cross validation constraints host cross validation groups. They never
> interfere. So the iplmentation does not really care if the same interface is
> reused.
>
> By the way @CrossValidation can host BV groups as it's a regular constraint.
>
> Back to cross validation use cases, could we list 3 or 4 use cases of cross
> validations and what do we expect them to do (error report wise). That will
> help to define the generic mechanism to define cross validation markers and
> implementations, as it is today, it seems @ExactlyOneNull would be hardcoded.
>
> Frankly, I wonder if the cross validation solution will end up being more
> verbose than the raw class-level approach :)
>
I wonder the same. As I have already said earlier, we developed cross
annotations as a way to try and compensate for the absence of class
level constraints (since we did not want to compromise with reusability) .
If class level validation is accepted and available, then there is
little point in cross annotations, unless we can come up with very
convincing use cases where cross annotations are clearly worth the added
complexity (in both implementation and usage).
Federico
> On 18 oct. 2010, at 11:11, Hardy Ferentschik wrote:
>
>> I was also thinking about a generic class level @CrossValidation constraint.
>> I think Emmanuel and I
>> are thinking about the same thing here:
>>
>> @CrossValidations({
>> @CrossValidation(forGroup=BankAccount.class),
>> @CrossValidation(forGroup=ContactDetails.class)
>> })
>> public class BankAccountNumber {
>>
>> @ExactlyOneNull(groups=BankAccount.class)
>> public String getIBAN() {
>> return IBAN;
>> }
>>
>> @ExactlyOneNull(groups=BankAccount.class)
>> public String getAccount() {
>> return account;
>> }
>>
>>
>> @ExactlyOneNull(groups=ContactDetails.class)
>> public String getHomeNumber() {
>> return homeNumber;
>> }
>>
>> @ExactlyOneNull(groups=ContactDetails.class)
>> public String getWorkNumber() {
>> return workNumber;
>> }
>> }
>>
>> Using groups (or maybe payloads!?) you can have multiple cross validations
>> of the same type within one entity.
>>
>> --Hardy
>>
>>
>> On Mon, 18 Oct 2010 09:48:16 +0200, Emmanuel Bernard<emman...@hibernate.org>
>> wrote:
>>
>>> On 16 oct. 2010, at 10:56, Dag Hovland wrote:
>>>
>>>> On 15/10/10 13:33, Emmanuel Bernard wrote:
>>>> (...)
>>>>> That being said, I wonder whether you can write your approach atop a
>>>>> generic class-level constraint @CrossValidation that would look for the
>>>>> properties annotations and behave as expected. That would be a nice way
>>>>> to offer both world to the users. You will need to "group" cross field
>>>>> constraints though: as I see it on the paper, you can only have one group
>>>>> of cross level constraint for a given constraint type per class.
>>>> I do not really understand this. Can you give an example?
>>> class BrokenModel {
>>> @AtLeastOneNotNullAmongst(Group1.class)
>>> A getA() { ... };
>>> @AtLeastOneNotNullAmongst(Group1.class)
>>> @AtLeastOneNotNullAmongst(Group2.class)
>>> B getB() { ... };
>>> @AtLeastOneNotNullAmongst(Group2.class)
>>> C getC() { ... };
>>> }
>>>
>>> A or B must be not null and B or C must be not null.
>>> _______________________________________________
>>> 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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
