LieGrue,
strub
----- Original Message ----
From: Matt Benson <[email protected]>
To: [email protected]
Sent: Thu, June 24, 2010 10:57:48 PM
Subject: Re: Dynamically applied constraints
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 <
href="mailto:[email protected]";>[email protected]>
To:
href="mailto:[email protected]";>bval-
[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
