bval-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <>
Subject Re: Dynamically applied constraints
Date Thu, 24 Jun 2010 23:13:33 GMT

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

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

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.


Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2010/6/24 Matt Benson <>

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

View raw message