Mailing-List: contact bval-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bval-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of gudnabrsam@gmail.com designates
 209.85.161.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=from:content-type:content-transfer-encoding:subject:date:message-id
         :to:mime-version:x-mailer;
        b=s2F//hDOg89tLgyZbm+R9MSJbN1zW+t95O5aqLrMyN2Hr69h9guZs6zRlJ7M1kvoPw
         Pg5w3SvWe9wNCzz9jZ1ItuEnxNgIPeWSLLOR4ov/vqlnodMpXTAMHPWQmi/QeyoAyd8s
         8o5E88R0GOEvmxoKhyJDHlRy5Y3S4uxVhOPhQ=
From: Matt Benson <gudnabrsam@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: Dynamically applied constraints
Date: Thu, 24 Jun 2010 13:47:25 -0500
Message-Id: <159838D8-A0B7-41CD-A2FC-E86B70EBA9E4@gmail.com>
To: bval-user@incubator.apache.org
Mime-Version: 1.0 (Apple Message framework v1081)

Hello all--
  I'm just getting my feet wet with JSR-303.  I started out using =
hibernate-validator, but as a foundation member and general connoisseur =
of Apache Kool-Aid I thought the very least I could do is give bval a =
fair shake.  So far, just browsing code and javadocs--my typical way of =
acquainting myself with an OSS project--I'm impressed, FWIW.

What I want to do is expose all my validation information to my =
controller/view layers per the standard APIs, and here's the catch:  =
*including* business-level validations which can be extremely dynamic in =
nature.  To be more explicit, I am in the insurance industry, which (in =
the US anyway) consists pretty much entirely of "special cases."

Firstly, is this considered out of scope of "Bean Validation" (the =
spec)?  bval?  If so, why?--It's my feeling that the spec intends that =
"validation" be quite an open-ended concept.  A blanket "don't do this" =
would simply make me question the overall usefulness of the spec.  =
However, it's obvious (at least, I *think* it is) that neither the =
annotation-based nor XML-based configuration methods can handle the =
dynamic application of constraints to a model.  At the same time I want =
to be able to use those configuration methods for the subset of =
validations that *can* be handled so globally.

I am thinking that I can reuse some of the underlying APIs from one of =
the existing Bean Validation implementations to maintain this dynamic =
information, then implement the ConstraintValidator for an e.g.  =
@DynamicValidation annotation to reuse others' machinery.  *This* I =
could configure in XML; best of both worlds.  So to put this into bval =
terms, I could maintain a MetaBean graph for each distinct model graph =
and dynamically apply constraints per graph.

This email has written itself in the sense that writing down my thoughts =
led to numerous edits and sculpted the above-outlined approach, which =
I'm tentatively feeling pretty good about, but I'd still like to get =
preliminary feedback from the community on the oh-shit level of the task =
I'm setting myself.

Regards,
Matt=