On Jun 29, 2010, at 8:49 AM, Donald Woods wrote: > > > On 6/28/10 3:03 PM, Matt Benson wrote: >> >> 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? > > No, just as code gets patched/reorganized it's up to the committer to > update the Javadoc/comments as they see fit. Of course, anyone can > contribute patches to add missing Javadoc and we'd be happy to commit it :-) > > 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. > > Great! Since you're an existing committer (and Member) we could look at > setting up our sandbox area in svn so you could create your own branch > to work on the changes until you're ready to have the community review > them for inclusion in trunk. Creating a new bval-dynamic module that > extends bval-jsr303 would be a great way to provide optional behavior, > like the existing bval-guice and bval-json modules. >
I'll let you know if I am able to come up with something that is both substantial and reusable, then. :) -Matt >> >> 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 >> >>
