On May 27, 2009, at 15:41, Hardy Ferentschik wrote:
On Tue, 26 May 2009 16:57:11 +0200, Emmanuel Bernard <emman...@hibernate.org
> wrote:
# 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
really independent
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.
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
