bval-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: Dynamically applied constraints
Date Fri, 25 Jun 2010 15:45:26 GMT

On Jun 25, 2010, at 5:06 AM, Mark Struberg wrote:

> Hi Matt!
>
> Prelude: The more discussion and different thoughts are brought up  
> early, the better we all will do in the end. So your valueable  
> input is highly welcome!
>
> For the shadow objects: this is not so easy to accomplish, think  
> about what happens if this is a deeply nested JPA object which  
> contains lots of 1:n relations which contain themselfs other  
> relations, etc. Some of them are lazy loaded, some of them eagerly  
> fetched, preloaded, ... An unconditional deep copy might not be  
> possible in this case (or doesn't make sense from a performance  
> perspective) and a simple toplevel copy might not be enough for  
> some cases.
>

Mark:  I am not carrying so much a full shadow graph as I have a  
means of calculating metadata for various points of the graph on- 
demand.  So far what I have has been pretty successful; integrating  
bean validation is pretty much the last piece of the puzzle.  :)

-Matt

>
> LieGrue,
> strub
>
>
> ----- Original Message ----
>> From: Matt Benson <gudnabrsam@gmail.com>
>> To: bval-user@incubator.apache.org
>> 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:gudnabrsam@gmail.com">gudnabrsam@gmail.com>
>>> To:
>>
>> href="mailto:bval-user@incubator.apache.org">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