Re: [rules-dev] validator

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(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