7:30 a.m.
Ok now I see it.
Using groups for cross-validation is a very nice solution to be able to
reuse them on multiple sets of properties.
Then in Emmanuel's example I guess it should be
@AtLeastOneNotNullAmongst(groups={Group1.class,Group2.class})
B getB() { ... };
The @CrossValidation annotation at class level is definitely a good idea
in order to avoid having a @CrossValidation marker inside
each cross-annotation, and it helps also the user/programmer to
distinguish between normal and cross annotations in the code.
I am a bit concerned about how groups for cross-annotations and normal
annotations would interact with each other.
Should it be possible to mix groups for normal and cross annotations
when defining a @GroupSequence?
Can both an annotation and a cross annotation belong to the same group?
If not, how to enforce that
(by the given example, the validator cannot distinguish between
cross-annotations and normal annotations, and therefore cannot perform
any check.
Of course I am assuming that you don't want to use a @CrossAnnotation
marker in the annotation declaration, or all of this would not be a
problem at all) ?
I can think of two ways right now:
1) We might have the cross-annotations themselves defined at class-level
rather than the groups. Like:
@Crossvalidations(CrossAnnotations={ExactlyOneNull.class,...})
In this way the validator (and the user) would know straight away which
are cross annotations and which not, and groups could still be used in
the same way at method level.
2.a) If a class defining a groups implemented some @interface Group"
then one could create something like "CrossGroup extends Group" and have
special groups reserved for cross-annotation:
@Crossvalidations(CrossGroups{BankAccount.class,ContactDetails.class})
The CrossGroup element in the annotation declaration would then work as
an implicit marker, so that annotations using those groups must be
cross-annotations and normal annotations would not be able to use them.
2.b) There exists a default group for all cross-annotations
en 18.10.2010 11:11, skrev Hardy Ferentschik:
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
<emmanuel(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev