Yes no-loop is pretty basic, its idea is to stop RuleA causing it to fire itself recursively. Of course, RuleA could cause RuleB to fire, which in turn causes RuleA to fire (no-loop is not designed to stop that).
To make sure things only fire once for the given facts, which I gather is what you want, as you say you need to have your own memory in your model of what has fired. Alternatively (perhaps, ideally) you do something like the "fish shop" example does regarding free samples: In your rule "customer-has-orders" where you add a free Gift CD, you can add a check to see if they already have a "gift CD" in the basket, and only add one if they don't. This ensures that the rule is always logically correct no matter when it fires. This has the added advantage that another rule may come along which adds a gift CD, which means that the rule I described would still be correct (otherwise they may end up with multiple Gift CDs, which would not be stopped by controlling the loop behaviour). Does that make sense? On 1/18/06, Ephemeris Lappis <[EMAIL PROTECTED]> wrote: > > Hello. > > I've tried to build a first simple case with potential loops. > > The rules script is attached (I hope the list supports attachments ?)… > I don't send the full project, but I can do it if needed. > > The test system is about customers, their placed orders, and the rules are > to select gifts that may be offered to customers depending on several > conditions. Gifts are selected and placed into a virtual 'basket' that > handles the decision process. > > Something like : > > - if a customer is 40 years old or more, we offer glasses. > - If a customer has already placed order for more than 2500 €, we may give > a CD. > - If the basket contains 2 gifts or more, we also give a bag to put them. > >
