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