incubator-bval-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: Dynamically applied constraints
Date Fri, 25 Jun 2010 00:22:03 GMT
hi,

@manipulation of bv-constraints on-the-fly:
you would have to implement a custom ValidatorFactory, ValidatorContext and
Validator.
it would be easier with a special spi provided by an implementation.
however, it wouldn't be portable.

@dependency injection:
you have to implement a custom ConstraintValidatorFactory for using
dependency injection in constraint validators (e.g. to delegate to a
different validation engine).

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/25 Matt Benson <gudnabrsam@gmail.com>

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

Mime
View raw message