The drools-expert documentation would be a good starting point; otherwise Wikipedia has a good overview of the RETE algorithm (all be it Drools has its own extensions).
Regarding your specifics; you could look into using a DSL for the domain experts rather than pure DRL. Also, the no-loop attribute could\should help with your looping fear (have a look in the documentation).
A rather disturbing example you choose to show in your email; I think I prefer the "Cheese" centric types in the documentation :)
Cheers,
Mike
Hi there,
We are evaluating Drools for an industry project. Trouble is, I'm not
good at ignoring men behind curtains, and need to know how things
actually work.
Links to papers explaining the theory and principles of Drools Expert
are highly appreciated.
Some specifics:
We have a network of domain objects, with basic attributes (numbers,
strings, enums) and two-way mapped associations.
Rules modify the basic attributes only. Associations (references and
reference sets) are static.
"where" conditions refer to both static information and modifiable attributes.
I was wondering how I can express this distinction in my domain
objects without sacrificing readability of the actual rules?
(Domain experts should be able to edit the rules themselves.)
Here's the current pattern of my rules:
rule "child molester"
where
$parent : Parent( ... )
$child: Child(parent==$parent ... attribute!="value")
then
modify ($child) { setAttribute("value") }
end
I'm not happy my users need to know about the setter methods instead
of using the same reflection-backed notation as in the condition.
I also worry they'll make infinite loops by omitting the
"attribute!=value" clause.
So I guess I should elevate the attributes to first class status in my
model to make them the atomic unit of triggering, but how do I do that
elegantly?
rule "attribute molester"
where
$parent : Parent( ... )
$attribute : StringHolder(get()!="value")
$child: Child(parent==$parent ... attribute=$attribute)
then
modify ($attribute) { set("value") }
end
That looks worse than before! Please share your thoughts.
Thanks in advance:
Gabor Szokoli
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users