Return-Path: Delivered-To: apmail-incubator-bval-user-archive@minotaur.apache.org Received: (qmail 89277 invoked from network); 24 Jun 2010 23:23:17 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 24 Jun 2010 23:23:17 -0000 Received: (qmail 97567 invoked by uid 500); 24 Jun 2010 23:23:17 -0000 Delivered-To: apmail-incubator-bval-user-archive@incubator.apache.org Received: (qmail 97536 invoked by uid 500); 24 Jun 2010 23:23:17 -0000 Mailing-List: contact bval-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: bval-user@incubator.apache.org Delivered-To: mailing list bval-user@incubator.apache.org Received: (qmail 97528 invoked by uid 99); 24 Jun 2010 23:23:17 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Jun 2010 23:23:17 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gudnabrsam@gmail.com designates 74.125.83.47 as permitted sender) Received: from [74.125.83.47] (HELO mail-gw0-f47.google.com) (74.125.83.47) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Jun 2010 23:23:08 +0000 Received: by gwaa12 with SMTP id a12so442066gwa.6 for ; Thu, 24 Jun 2010 16:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:mime-version :content-type:subject:date:in-reply-to:to:references:message-id :x-mailer; bh=MOTjTuK8U0jioGKx9vvjzFhgaDjDobQ/6VcUYVoXkB4=; b=J8Ef9H2MYqnbGv/gYwYz8ZBacseE3oVkI6hsEqXyf+b0sUVHRe8JkoWizD6svkYnfz dJbJLRw+b3irdxa1IPw4M8pyP1lRe5imVGreb8Swv8yFcap8OIAYgTxRQ29KsvUVu4/1 /mrIRXvtClvMdxDBvGoJe1pR9vyVYd7N0L01I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=Jk3Yfi17dyfxWrewtmRXTV/Trq5MjaENyOeY/VqBIIFcEkhb6fPWzaxeom68GyFyWE S/3E6phSc/Sek5uXq6ca5FMLzfQ7E0ysqmpdaYEM+he/LrfoKce3qgvmOs0RzIsjoLnF hqAgw4PtvuHGJhDcFo1sV1rnqrjWZyzhfXReI= Received: by 10.100.128.13 with SMTP id a13mr9302860and.159.1277421767132; Thu, 24 Jun 2010 16:22:47 -0700 (PDT) Received: from [192.168.1.13] (adsl-068-213-090-227.sip.bhm.bellsouth.net [68.213.90.227]) by mx.google.com with ESMTPS id t27sm608097ybi.19.2010.06.24.16.22.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 24 Jun 2010 16:22:46 -0700 (PDT) From: Matt Benson Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-2-614335841 Subject: Re: Dynamically applied constraints Date: Thu, 24 Jun 2010 18:22:42 -0500 In-Reply-To: To: bval-user@incubator.apache.org References: <159838D8-A0B7-41CD-A2FC-E86B70EBA9E4@gmail.com> <668796.63467.qm@web27801.mail.ukl.yahoo.com> <5625B862-1002-4D2E-9945-9DD64EED141A@gmail.com> Message-Id: <1E1ABE86-C8DA-461F-B629-B47B0F424EFD@gmail.com> X-Mailer: Apple Mail (2.1081) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-2-614335841 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 24, 2010, at 6:13 PM, Gerhard Petracek wrote: > hi, >=20 > basically i agree with mark. >=20 > some additions: >=20 > 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.) >=20 > 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). >=20 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. >=20 > @"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. >=20 > regards, > gerhard >=20 > http://www.irian.at >=20 > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German >=20 > Professional Support for Apache MyFaces >=20 >=20 > 2010/6/24 Matt Benson >=20 > On Jun 24, 2010, at 3:32 PM, Mark Struberg wrote: >=20 > > Hi Matt! > > >=20 > Hi, Mark. Thanks for your response (note, all, that this doesn't = preclude additional responses). :) >=20 > > 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). > > >=20 > Yes, I've become very familiar with that concept recently. :) >=20 > > 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=3D6 and j=3D8 ? > > As you can see, this really depends on the order in which the fields = get set. > > You can easily set i=3D6 as long as j is not yet filled. But what = happens then? While trying to set j=3D8 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=3D6 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=3D6 should have been revoked. > > >=20 > I would argue that this is an example of a misconfiguration, and = nobody has any business being upset when it fails. ;) >=20 > > 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. > > >=20 > 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. >=20 > > 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? > > >=20 > 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. >=20 > > 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... > > >=20 > 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. >=20 > -Matt >=20 > > > > > > ----- Original Message ---- > >> From: Matt Benson > >> To: bval-user@incubator.apache.org > >> 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 > > > > > > > > >=20 >=20 --Apple-Mail-2-614335841 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
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 <gudnabrsam@gmail.com>

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 <gudnabrsam@gmail.com>
>> To: bval-user@incubator.apache.org
>> 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
>
>
>
>



--Apple-Mail-2-614335841--