<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Am 24.02.2010 08:37, schrieb Wolfgang Laun:
<blockquote
cite="mid:17de7ee81002232337l22e54a64n660693632210ade5@mail.gmail.com"
type="cite">You really ought to read all the pertaining sections in
the Drools Expert manual and experiment. Nobody can write complex rules
without some exercise.<br>
<br>
<div class="gmail_quote">2010/2/24 dhari <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:sdhari@hotmail.com">sdhari@hotmail.com</a>></span><br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<p>Thanks Jeffery.
I'll try this but what if I have more complex condition e.g. </p>
<p><br>
Order ($discount : discount, $items : items)<br>
Item(grade > 3 && (quantity < 5 || $discount > 10))
from $items</p>
</blockquote>
<div><br>
Again, you are using a condition on discount not next to the field in
the fact where it occurs (i.e., Order); it's just not possible to write
it this way.<br>
<br>
Order( discount > 10, $items : items ) # all Orders where discount
> 10 <br>
Item( grade > 3, quantity < 5 ) from $items # and each of its
Items where grade > 3 and quantity < 5<br>
<br>
There is no need to use && to combine two conditions for the
same fact.<br>
<br>
Now if you need to detect Order Items with grade > 3 where either
the quantitiy of the Item is < 5, or the Order's discount > 10,
(or both) you'd have to write<br>
<br>
Order( $discount : discount, $items : items ) # all Orders<br>
Item( grade > 3, $quantity : quantity) from $items # and each of its
Items where grade > 3<br>
eval( $discount > 10 || $quantitiy < 5 ) # and discount > 10
or quantity < 5 (or both)<br>
</div>
</div>
</blockquote>
<br>
Hi!<br>
<br>
Another technique we commonly use at my employer to break up overly
complex rules is to "factor out" subexpressions, preferrably using
locally declared fact types to express the subexpressions, e. g.:<br>
<br>
declare ItemPreventingDiscount<br>
item: Item<br>
order: Order<br>
reason: String<br>
end<br>
<br>
rule "Prevent discount > 10 for items graded > 3"<br>
when<br>
$order: Order(discount > 10, $items: items)<br>
$item: Item(grade > 3) from $items<br>
then<br>
ItemPreventingDiscount fact = new ItemPreventingDiscount();<br>
fact.setItem($item); // optional<br>
fact.setOrder($order); // optional<br>
fact.setReason("discount percentage > 10 not valid for items
graded > 3");<br>
insertLogical($fact);<br>
end<br>
<br>
// add more rules to prevent other combinations of discount, quantity,
... whatever<br>
<br>
rule "Issue error message if items preventing discount exist"<br>
when<br>
exists( ItemPreventingDiscount( $reason: reason, $item: item ) )<br>
then<br>
System.out.println("Discount not allowed: Item '"+
$item.getDescription() + "' prevents discount because " + $reason +
".");<br>
end<br>
<br>
One might debate whether it is already appropriate to factor out
subexpressions for this still rather simple example, yet our experience
is that in general it leads to code with an improved readability. I'd
go so far to suggest that whenever you're struggling with the syntax of
the language you're using to solve a problem, ask yourself whether
you're trying to achieve too much with too little code. The answer is
of course depending on your level of experience with the language,
nevertheless you (the author of the code) probably want to be able to
read and understand the code at any time.<br>
<br>
Kind regards<br>
<br>
Ansgar<br>
</body>
</html>