[rules-dev] validator

[Edson Tirelli]

   Well, we can't let the the exception escape the consequence block, since
it would invalidate the working memory.
   So, we have 2 options I think:

* If we make the validation framework enforce valid values, we need it to
raise an exception that is catch by a transparent consequence catch block
and is handled the same way we already handle them, but stopping rule
firing.

* If we make the validation framework just warn about invalid values, we can
create a warning mechanism so that users can handle such warnings, but let
the value to be set and continue running the engine as if no problem was
found.

   I don't see many other options on that... I still prefer first option.

   My 0.02c.

   []s
   Edson

2008/1/8, Mark Proctor <mproctor at codehaus.org>:
>
> 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
> >
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>



-- 
  Edson Tirelli
  JBoss Drools Core Development
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20080108/50dfc3e5/attachment.html