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