incubator-bval-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: Dynamically applied constraints
Date Mon, 28 Jun 2010 18:52:12 GMT

On 6/24/10 2:47 PM, Matt Benson wrote:
> 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.

Matt, these are exactly the type of ideas/features that we should be
discussing for inclusion in future releases.  We can always provide
additional features beyond the spec, as long as we denote them as being
implementation specific....


> 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

View raw message