[hibernate-dev] [Bean Validation] Groups and Group sequence
On Feb 6, 2009, at 02:37, Sebastian Thomschke wrote:
> Also I could not find the answer in the spec for the following:
>> @GroupSequence(sequence = {GroupA.class, GroupB.class}
>> interface MyGroup extends GroupC, GroupD { }
>>
>> => my guess is, this is a group of GroupA,GroupB,GroupC,GroupD where
>> GroupA and GroupB must be validated first.
>>
>> I wonder if it would make sence to change this to something like
>> this:
>>
>> @Group(sequence = {GroupA.class, GroupB.class}
>> interface MyGroup extends GroupA, GroupB, GroupC, GroupD { }
>>
>> In this case the aggregation of groups is always done via
>> inheritance
>> and only the ordering is done via an annotation. The constraint
>> would be
>> that the group must inherit directly or indirectly the classes
>> listed in
>> the sequence parameter.
>>
>> Any thoughts?
> hum I will need to think harder about that one. not in the mood right
> now. Give me time.
I am eagerly waiting for your response :-)
So that's a complex topic :) And it unveiled some underdefined parts
in the spec.
It also raised more questions than answers. so anyway here we go.
Please comment on each case.
1. Can an annotation declaration use a group sequence name?
Initially I thought that a sequence was here for the sole purpose of:
- redefinining the Default group of a class
- a group defined and used at validation time ie
validator.validate(object, groupSequenceName)
Should we allow a GS to be used in a declaration
@GroupSequence(sequence=LightBillable.class, HeavyBillable.class)
interface Billable {}
@NotNull(groups=LightBillable.class)
CreditCard defaultCreditCard;
@NotNull(groups=Billable.class)
Address defaultBillingAddress;
And in this case, should the GS name group be validated in parallel to
the actual group sequence constraint.
While I don't think it's a great practice to use group sequence names
in a constraint declaration, I haven't found a compelling argument
against it.
WDYT?
Likewise
2. Should we allow superinterfaces on GroupSequence definitions?
same question, same arguments as 1.
3. When defining sequence between two groups, should their supergroups
be naturally ordered?
* I can find cases where "inherited" ordering make sense
interface LightBillable extends Default {}
interface HeavyBillable {}
@GroupSequence(sequence=LightBillable.class, HeavyBillable.class)
interface Billable {}
We want Default to be validated before HeavyBillable.
* I can find cases where "inherited" ordering is annoying
interface SafeUser {}
interface Billable extends Default, SafeUser {}
interface Shippable extends Default, SafeUser {}
@GroupSequence(Billable.class, Shippable.class)
interface CanOrder {}
Billable, SafeUser, Default must be before Shippable, SafeUser,
Default which is impossible ( SafeUser befire Default and Default
before SafeUser).
But realistically, such a constraint would better off be modeled as
interface SafeUser {}
interface Billable {}
interface Shippable {}
@GroupSequence(Billable.class, Shippable.class)
interface CanOrder extends Default, SafeUser {}
or
interface SafeUser {}
interface Billable {}
interface Shippable {}
interface ValidAndBillable extends Default, SafeUser {}
@GroupSequence(ValidAndBillable.class, Shippable.class)
interface CanOrder {}
4. Should we consider group sequence as orthogonal to inheritance as
described by Sebastian
interface SafeUser {}
interface Billable {}
interface Shippable {}
interface ValidAndBillable extends Default, SafeUser {}
@GroupSequence(ValidAndBillable.class, Shippable.class)
interface CanOrder extends ValidAndBillable, Shippable {}
Pro side:
Any circular dependency between group sequences / inheritance is
caught by the compiler (though, a sequence incompatibility is not).
Con side:
@GroupSequence used by classes to override the default sequence will
not follow this rule
@GroupSequence(Default.class, HeavyUserValidation.class)
class User { ... }
Comments welcome.
Once we answer the question, I will adjust the group formal definition
(should be easy) and clarify what group sequence means.