You are very right that the problem could be eliminated if the rules are modified in this way and try to use module in this way seems overkilled
But actually I try doing in this way is mainly for packaging purpose; so that the rules could be grouped into separated rules files. For examples, there could be 3 files 1) one rule file for the dispatcher rules and core logic rules 2) specific logic rules set A (ModuleA) 3) specific logic rules set B (ModuleB) so that file 2 & 3 could be replaced rather easily. However, if I need to write the module names with the rules, it seems I need more efforts in switching the rule files. Does anyone have similar experience? Please share with me, Thx! Thank you very much!! Best Regards, folderman Ernest Friedman-Hill wrote: > > Sure, you would have all kinds of problems with a design like this; > it's a bad idea. Get rid of the Dispatcher rule, write the individual > rules like this: > > (defrule ModuleA::RulesA > (declare (auto-focus TRUE)) > ?context <- (MAIN::FactX(OBJECT ?contextObject) (env ModuleA)) > ... > > Two things are happening. First, since Jess has the auto-focus > feature, why not use it? You're just slowing things down by using a > rule to do the same work. Second, as you originally wrote them, > RulesA and RulesB both matched exactly the same facts; you need to > write them so that they match only the facts you want processed by > the given module. This last change very easily eliminates the whole > problem you're concerned about. > > > > On Jul 4, 2007, at 9:55 PM, folderman wrote: > >> >> Thank you very much for the quick response first of all. >> >> Actually, I'm not using the "auto-focus" keyword, instead I would >> focus a >> specific module in my code based on the incoming fact. >> >> Suppose I have rules on a Fact (typed "FactX") in both ModuleA and >> ModuleB, >> i.e. >> >> (deftemplate MAIN::FactX >> (declare (from-class test.FactX) >> (slot-specific TRUE))) >> >> (defrule MAIN::Dispatcher >> "Dispatcher" >> ?context <- (MAIN::FactX(OBJECT ?contextObject) (env ?env1)) >> => >> (focus ?env1)) >> >> (defrule ModuleA::RulesA >> "Dispatcher" >> ?context <- (MAIN::FactX(OBJECT ?contextObject) (env ?env1)) >> => >> (print "running in moduleA")) >> >> (defrule ModuleB::RulesB >> "Dispatcher" >> ?context <- (MAIN::FactX(OBJECT ?contextObject) (env ?env1)) >> => >> (print "running in moduleB")) >> >> So my concern would be that, would there be chances for a FactX >> with the >> "env" attribute = "ModuleB", would get running in ModuleA, when it is >> asserted into the rule engine while there is another fact already >> running in >> ModuleA and thus the current focus "ModuleA" during the assert time? >> >> What's more is that there might be more than 1 rules in the >> modules, and >> would the fact triggering the rules in the other module during >> execution? >> >> Thank you very much!! >> >> Best Regards, >> folderman >> >> >> >> Ernest Friedman-Hill wrote: >>> >>> If a rule is declared as "auto-focus", then when it is activated, it >>> will change the focus module to its own module. But in the absence of >>> this declaration, an activated rule in a non-focused module will just >>> sit and wait for its module to be focused again; it will not fire >>> immediately, >>> >>> >>> On Jul 3, 2007, at 11:26 PM, folderman wrote: >>> >>>> >>>> Hi everyone, >>>> >>>> I'm currently integrating JESS into my web application and the >>>> architecture >>>> is typical; running rete.runUntilHalt() and asserting a shadow fact >>>> for an >>>> incoming HTTP request. But as more and more rules are developed, I'm >>>> thinking to partition the rules into modules. >>>> >>>> Now, suppose I have 2 module, moduleA and moduleB, and some rules >>>> are >>>> defined to match the same set of shadow facts on the LHS. In >>>> essence, I >>>> could "switch" the execution logic by either focusing moduleA or >>>> moduleB, >>>> and the decision for which module gaining control is depends on the >>>> screen >>>> the user is in. >>>> >>>> However, there is an incoming the fact which should be running in >>>> moduleB >>>> but there might be chances that rule engine is processing another >>>> requests >>>> and moduleA is the current focus; if the incoming fact is assert at >>>> that >>>> time, it might be running moduleA instead of moduleB. >>>> >>>> So, might I confirm if the above scenario would happen? Is there any >>>> workarounds to avoid the unnatural execution? What would be the >>>> orthodox way >>>> to implement the module control flow then? Any help or opinion >>>> would be >>>> appreciated. >>>> >>>> Thank you very much, everybody!! >>>> >>>> Best Regards, >>>> folderman >>>> >>>> -- >>>> View this message in context: http://www.nabble.com/Module-and- >>>> Concurrency-tf4022222.html#a11424331 >>>> Sent from the Jess mailing list archive at Nabble.com. >>>> >>>> -------------------------------------------------------------------- >>>> To unsubscribe, send the words 'unsubscribe jess-users >>>> [EMAIL PROTECTED]' >>>> in the BODY of a message to [EMAIL PROTECTED], NOT to the list >>>> (use your own address!) List problems? Notify owner-jess- >>>> [EMAIL PROTECTED] >>>> -------------------------------------------------------------------- >>> >>> --------------------------------------------------------- >>> Ernest Friedman-Hill >>> Advanced Software Research Phone: (925) 294-2154 >>> Sandia National Labs FAX: (925) 294-2234 >>> PO Box 969, MS 9012 [EMAIL PROTECTED] >>> Livermore, CA 94550 http://www.jessrules.com >>> >>> -------------------------------------------------------------------- >>> To unsubscribe, send the words 'unsubscribe jess-users >>> [EMAIL PROTECTED]' >>> in the BODY of a message to [EMAIL PROTECTED], NOT to the list >>> (use your own address!) List problems? Notify owner-jess- >>> [EMAIL PROTECTED] >>> -------------------------------------------------------------------- >>> >>> >>> >> >> -- >> View this message in context: http://www.nabble.com/Module-and- >> Concurrency-tf4022222.html#a11439857 >> Sent from the Jess mailing list archive at Nabble.com. >> >> -------------------------------------------------------------------- >> To unsubscribe, send the words 'unsubscribe jess-users >> [EMAIL PROTECTED]' >> in the BODY of a message to [EMAIL PROTECTED], NOT to the list >> (use your own address!) List problems? Notify owner-jess- >> [EMAIL PROTECTED] >> -------------------------------------------------------------------- > > --------------------------------------------------------- > Ernest Friedman-Hill > Advanced Software Research Phone: (925) 294-2154 > Sandia National Labs FAX: (925) 294-2234 > PO Box 969, MS 9012 [EMAIL PROTECTED] > Livermore, CA 94550 http://www.jessrules.com > > -------------------------------------------------------------------- > To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' > in the BODY of a message to [EMAIL PROTECTED], NOT to the list > (use your own address!) List problems? Notify [EMAIL PROTECTED] > -------------------------------------------------------------------- > > > -- View this message in context: http://www.nabble.com/Module-and-Concurrency-tf4022222.html#a11457975 Sent from the Jess mailing list archive at Nabble.com. -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] --------------------------------------------------------------------
