On Jun 28, 2010, at 1:52 PM, Donald Woods wrote:

> 
> 
> 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....
> 

I am trying to consume the API and get a feel for what I want to recycle.  On 
that note, are there any current plans to improve bval's javadocs?  On the 
original subject:  If possible/practical I would be glad for my work to form 
the basis of a dynamic validation model in bval.

Regards,
Matt

> -Donald
> 
> 
>> 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

Reply via email to