One thing that people missed that may be interesting is the fact aliasing. So in the simplest case this is simply renaming a fact so instead of:
FooBar() in a rule, you could write YourFabulousObject(). That is clear enough. What would be interesting is the following: FooBar(someField == "abc") aliased too SomethingElse() so the someField == "abc" constraint is always implicitly applied. I could see this being useful, especially when generic facts are used.. this could be Thoughts - any one wanna have a crack at implementing this? On Sat, Jul 19, 2008 at 3:31 AM, Mark Proctor <[EMAIL PROTECTED]> wrote: > Found this: > http://www.ilog.com/products/jrules/documentation/jrules67/rtsohelp/wbg_config7.html > "A ruleset parameter is the equivalent of a global variable" > > So a ruleset parameter is nothing more than a global, so just use our > globals as is and you get IN_OUT capabilities. I would strongly advise you > against representing your entire model this way and just using evals. > > Mark > > > Mark Proctor wrote: > > Yoni Mazar wrote: > > Hi all, > We are at the begining of a new clinical decision-support project. We plan > using drools (using Eclipse) in order to manage and execute our > business logic. As part of our research, we also evaluated JRules which has > a feature that > is very important to us and we could not find in Drools. > > I've reference the ilog manual on in/out parameters if anyone doesn't know > what they are: > http://www.ilog.com/products/jrules/documentation/jrules67/rsruleset/rs_rls_parameters.html#1026848 > http://www.ilog.com/products/jrules/documentation/jrules67/rsruleset/rs_rls_tskcreatingrulesetparams.html > > I don't see the difference between a global and an IN_OUT parameter, and I > don't see the value of specifically saying which parameters are IN and which > are OUT. It doesn't seem that parameters are facts, they are not asserted > into the engine and propagated through the working memory - atleaast I don't > think they are, the manual doesn't say clearly enough, it just says they can > be referenced from any ruleset component, which seems to be akin to how we > do globals. > > Unless we missed it out, we will probably try and add this functionality > ourselves. > > In JRules, one can define a ruleset (corresponds to a package) with > parameters. Each parameter has a datatype (a class), a direction > (in/out/inout), and an alias. Then, within the rules, the user can refer to > the parameter alias. For > example, a user can define a ruleset with the following parameters: > *class=LabResult, direction=in, alias=hemoglobin *class=LabResult, > direction=in, alias=creatinin > Then, within a rule, one can write: when hemoglobin.value<10 and > creatinin.value>34 then... > > We can do the same with globals, but what that actually means is you have a > rule that doesn't use any working memory objects, and you put the > constraints into one big eval - no pattern matching, so you are turning the > rule engine into a scripting engine rather than a production rule system. > > If they are indeed facts that allow for pattern matching, then it seems that > they constraint by the variable name rather than by object type. I've never > liked this, again why not just use mvel directly as a scripting engine. But > I have thought of how this would be possible, somethign I call Named Facts - > where asserted facts can be given a unique string identifier and a pattern > can be told to not only constraint against that object type, but also > against that variable name. However this is something that users can emulate > themselves now, by just putting an "identifier" field on their facts and > constraining on it in the pattern. If someone comes up with a clean way for > supporting named facts and provides a patch we will consider including it, > but it's not one of our priorities at the moment. > > > Now, the application retrieves the patient data accordingly (hemoglobin and > creatinine data separetly - even though they are of the same type) and sets > the ruleset parameters: ruleset.parameters.add("hemoglobin",hemoglobinFact) > ruleset.parameters.add("creatinin",creatininFact) > It is important that the definition of the aliases will be done outside of > the rule (and not by defining in-rule variables) > > This approach simplifies the rules since some of the filtering is being > applied externally (not in the rule itself) > > > sounds like it simplifies it, by turning it into a scripting engine where > all facts are variables with identifiers. > > Does someone has an idea how to bridge this gap using Drools? Are there any > workarounds that can be used in order to avoid changes in > code? > > > Hopefully my main paragraph above shows you how to emulate this. > > And here we can use your help: > We are new to Drools (and still have to dive into the big ocean of code that > exists). The following features > > 1) defining parameters (in the package level...something like import) > 2) adding in/out modifiers (can be used in LHS, RHS, or both) > 3) allowing assignment of aliases to parameters 4) adding such functionality > to the rule editor (auto-complete ,type safety) > > Where should we start? > Do you have any ideas that can help start this process (e.g. relevant > classes, modules)? > We would appreciate any help regarding any of the items in the list above. > Any hints, suggestions, directions, referals and so on. > > > IF IN_OUT params are nothign more than globals and big fat evails, then you > have nothing to do. > > If they are named facts, it won't be easy, but you could try the following > approach: > 1) update drools to support named facts, as described previously, this will > involve a special type of ObjectType I imagine, and you'll have to change > how it matches ObjectTypes so that it also has access to the possible > variable name. > 2) figure out a sane syntax, that is not ambigious, to allow pattern > matching on named facts, and update our Antlr files to support this. > 4) I don't konw if in/out parameters are useful for a stateful session, or > only stateless. Either way you will probably want to create some Context > object that contains these parameters and then you "insert" them using > smething like insertWithParameters( myParams ). With stateless it'll execute > and return results directly, with stateful you'll have to figure out how > that'll work with possible incremental inserts and fireallrules being called > separately. > 4) Write lots of tests ot make sure it doesn't break anything > > Thanks a lot. > > Yoni > > > > > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev > > -- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
