[rules-users] new to Drools: modeling issues

[Michael Anstis]

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

On 6 December 2010 09:15, Gabor Szokoli <szocske at gmail.com> wrote:

> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20101206/5d3fb55e/attachment.html