[rules-dev] validator

[Mark Proctor]

Michael Neale wrote:
> I don't like the catch block idea at all. We have a rule language not 
> a programming language.
How do we deal with invalid sets? Without a catch block, ther "then" 
scoped or "modify" scoped, we have only two choices - always throw an 
exception, do nothing and just expose a validator variable. Considering 
we don't want to add 'if' statements into the consequence how would the 
user then handle processing the validator variable?
>
>
> 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
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>