On Jun 24, 2010, at 6:13 PM, Gerhard Petracek wrote: > hi, > > basically i agree with mark. > > some additions: > > there was no intention to support manipulation of bv-constraints on-the-fly. > (that's one of the reasons why e.g. myfaces extval still provides an > alternative validation-module which supports more dynamic use-cases for jsf > applications.) > > however, for "special" cases you can use e.g. group validation and/or > class-level validation. > beyond that it's possible to implement some custom mechanisms to extend the > std. features of bv or to delegate some parts of the validation-process to a > different validation-engine (e.g. via a constraint-validator which uses > dependency injection). >
That's more or less what I'm planning to do here. :) Thanks, Matt > anyway, imo it's better to discuss use-cases as well as possible solutions > with concrete examples. if there is a common scenario and we find a nice and > >generic< solution for it, we could prototype the solution in a special > branch. as soon as it works we could provide an add-on for bv. if we need > e.g. a new bv-api, i would suggest it in the eg for the next version of bv. > > @"shadow instances": > some weeks ago i've started a discussion about transactional validation in > the eg. (+ i prototyped different solutions as extval-add-on.) > to provide a complete solution for it we would need proxies. -> we postponed > the discussion. > > regards, > gerhard > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > 2010/6/24 Matt Benson <[email protected]> > > On Jun 24, 2010, at 3:32 PM, Mark Struberg wrote: > > > Hi Matt! > > > > Hi, Mark. Thanks for your response (note, all, that this doesn't preclude > additional responses). :) > > > Interesting thoughts, but I'm not sure if JSR-303 is the golden bullet for > > business validations. To be honest, I personally doubt it ;) > > > > The thing is there is still the famous old 80:20 rule out there: 80% of the > > use cases / processes take 20% of the effort, but the very little rest > > which is left (all the 'exceptional' cases) will cost you 80% of the whole > > budget (money and time wise). > > > > Yes, I've become very familiar with that concept recently. :) > > > Why do I do all those prays? Because I personally think that more complex > > business validations should still be programmed in the business code > > because they are so complex that there is no easy way to 'configure' them. > > Maybe it can be done by configuration, but most probably simply coding it > > will be easier. > > > > It's like with all meta-languages: the more powerful they become, the more > > complex they get. And often they grow more complex than having a general > > purpose programming language + a few small helper libraries for your > > special problem. > > > > Take for example a simple multi field cross - validation. This seems sooo > > easy at the first glance, but it is _really_ hard to do it right! > > > > assumption: it should not be possible to set wrong values into your data > > beans. > > > > This sounds easy, because you just need to validate each field before you > > actually set the value. But let's consider a bean (heavily simplified and > > meta coded) > > public class BeanX { > > @MustBeZero if field j > 3 > > int i; > > > > @MustBeZero if field i > 3 > > int j; > > } > > > > > > And now what happens if you like to set i=6 and j=8 ? > > As you can see, this really depends on the order in which the fields get > > set. > > You can easily set i=6 as long as j is not yet filled. But what happens > > then? While trying to set j=8 the 2nd field validation fails. So this > > situation is obviously not allowed. But in what state are we now? We > > already allowed to set i=6 which is only half of the truth! We basically > > trashed our bean, because ideally it should still contain the old values > > and even setting i=6 should have been revoked. > > > > I would argue that this is an example of a misconfiguration, and nobody has > any business being upset when it fails. ;) > > > I don't think there is a way to work around this without introducing a > > complete shadow instance of the bean. But this is only the peak of the > > iceberg - there are sooo many other much more difficult situations out > > there. > > > > To disclose further, a shadow instance of the bean is very nearly what I am > working with: a collection of metadata for a graph's properties (in case > you're concerned about me at this point, I will go on to disclose that they > are lazily and dynamically generated wherever possible). In fact, I began > this layer of my project with my own notion of a property constraint; I'd > just like to migrate that to be a ConstraintDescriptor and cut down on > reinventions of wheels where I can. > > > To relativate this - I now work with JSR-303 in a EE6 project since > > december last year (being a really early adaptor) - and in those 80% of the > > cases JSR-303 eases my life HEAVILY. I'd say the rate is even much higher - > > close to 98% (*). But there are still those 2% where I rather code my > > business rules in Java than I configure an utterly complex JSR-303 ruleset. > > > > So while having a dynamic ruleset seems cool from the first glance, I'm not > > sure if the old-fashioned way of just coding it wouldn't be much easier? > > > > What I currently have is the ability to use Java and/or Drools to apply > constraints to my graph. So I am, as you recommend, implementing a business > rule in whatever way is the best combination of [quicker|easier|more > maintainable] to _set_up_ the constraint for querying and validation. I > honestly haven't heard anything to make me believe that, for my existing > structure, the approach I outlined before is not reasonable. > > > LieGrue, > > strub > > > > (*): to make this more clear: JSR-303 really rocks, because you will get > > rid of manually hacking most of the 'dumb' validation code which is always > > the same over and over again... > > > > Strangely, I have very little to perform in the way of dumb/repetitive > validations; the vast majority of what I need is context-dependent. I simply > can't resolve myself to the notion that ALL my validation information, of > whatever complexity, should not ultimately be funneled through a single > point. At this point you've not managed to dissuade me from my plan, though > I repeat my appreciation of your willingness to discuss it. > > -Matt > > > > > > > ----- Original Message ---- > >> From: Matt Benson <[email protected]> > >> To: [email protected] > >> Sent: Thu, June 24, 2010 8:47:25 PM > >> Subject: Dynamically applied constraints > >> > >> 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 > > > > > > > > > >
