On May 27, 2009, at 15:41, Hardy Ferentschik wrote:
On Tue, 26 May 2009 16:57:11 +0200, Emmanuel Bernard <emmanuel(a)hibernate.org
>> # background
>> When validating a specific group(s), Bean Validation expends the
>> group into a sequence of groups to be validated (because a group can
>> be a group sequence really). Depending on how clever the
>> implementation is, it could sequencialize all group execution or try
>> to validate several non sequenced group in parallel.
We are already doing the sequencialize part. In our case we are
populating a 'GroupChain'
Yes but last I checked (pre vacations) we do not run several groups
in //. We sequentialize them
object, but the idea is the same. However, this sequencializing is
from the defined constraints. One can determine the group execution
order without actually
evaluating the entities. I think group sequencialize and actual
validation are orthogonal
and should stay this way.
it's almost orthogonal. The default sequence overriding ruins your
beautiful dream :)
A sequencing is a function of the groups requested and the default
sequence overriding of the class requested
I am also not sure why we should add
validator.getConstraintsForClassAndGroups to the Validator
interface? The Validator interface is the main contract between Bean
Validation and a client.
It allows to either validate an object or get some meta information.
The latter is probably mainly
used for tooling. Where would
validator.getConstraintsForClassAndGroups fit into this?
Why would we expose this call to a client?
A JS generator would call getConstraintsForClassAndGroups() to receive
the list of constraints it ought to translate. The more I think about
it, the less I think getConstraintsForClass is useful as the groups
rules are quite complex.