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@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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev