Re: [rules-dev] validator

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(a)codehaus.org&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev