[rules-dev] validator

[Michael Neale]

I don't like the catch block idea at all. We have a rule language not  
a programming language.


Sent from my iPhone

On 08/01/2008, at 6:49, Mark Proctor <mproctor at codehaus.org> wrote:

> I'm thinking about an ontology constraint system, based around field  
> setter validation. However I cannot decide how to handle invalid  
> changes in a consequence or in external java code. I'll may leverage  
> the JSR 303 - Bean Validation - http://jcp.org/en/jsr/detail?id=303.
>
> Although I have several concerns with the spec, one is that it  
> always validates objects and passes in the field as an object - with  
> primitive intensive stuff that can add an overhead, due to auto  
> boxing. I'm more tempted to pass in the main Object itself and users  
> can then use the FieldExtractor to read the field as they require,  
> either as an Object or a primitive with full co-ercion - the  
> FieldExtractor would be injected. Further to that I can't see how  
> you would make the validator session aware, and doing it via  
> constructor injection would mean a validator per session which is  
> not desirable. I spoke to the spec lead and he mentioned using  
> LocalThread variables. However we can have multiple sessions in the  
> same thread, just not executing at the same time, which means the  
> current executing session would need to set itself on that  
> localthread variable - basically context switching, which I don't  
> like.
>
> We should have a variable that lists the validator errors for the  
> current working memory action phase, for user interrogation - much  
> like Hibernate Validator (RI for JSR 303) allows you to list  
> validation errors on a insert or update on a session.
>
> But in rule engines we have other considerations:
> The first fundamental question is do we allow invalid changes or do  
> we always roll them back? My prefernce, much like a database, is the  
> data model as seen by the engine is always valid.
>
> Now if we assume the invalid change must be rolled bank or not  
> applied how do we expose this to the user:
> -Throw an exception, up to them if they catch and it will exit the  
> engine if not caught.
> -Do nothing, roll back the change and continue executing the  
> consequence as normal, they can check the validator variable if they  
> need to.
> Allow for "catch" like blocks either after each modify block, or  
> after the "then" block. Do we have one large catch block, or do we  
> have some sort of type matching....
>
> Currently my preference is for a "catch" block after the "then"  
> block. I'm tempted to just have one large catch block and users can  
> do an iteration of the validator variable doing "if" checks; we can  
> always add in type matching later. The catch block can either resume  
> or throw an exception; on resumption it will attempt to validate the  
> bean again, if it's changed, if it's still invalid the process  
> repeats.
>
> Mark
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev