3:15 a.m.
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
3:26 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4:36 a.m.
Thanks for the instant response!
2010/12/6 Michael Anstis <michael.anstis(a)gmail.com>:
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).
I'm reading the documentation thoroughly of course, but it seems to be
centered about using the system and writing rules. Which is how it
should be, don't get me wrong :-)
I'm just hoping for some spoilers like "Section X will detail how java
object are mapped to WMEs."
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).
Can I put off the DSL part for later, and consider it just an extra
layer of rule file parsing for now?
Do I lose the graphical on-line editor features of Guvnor (which I
admittedly have not looked into yet, just salivated over some
screenshots.) if I make a DSL?
A rather disturbing example you choose to show in your email; I think
I
prefer the "Cheese" centric types in the documentation :)
Other than the attention-whoring double take in nomenclature, does
that rule pattern look OK?
I'll stick with cheese in the future :-)
Thanks Again!
Gabor Szokoli
4:54 a.m.
Glad you're reading the documents - you'd be surprised how many people
asking questions do not!
You can put off DSL until you're happy your rules are working, off course -
in fact, IMO, it's easier to "debug" rules without the additional
abstraction.
You're first rule looks better - although I'd still be inclined to look at
no-loop rather than the check yourself (what if you need the new value to be
dynamic; i.e. not just statically "value"? Your rules would become
cumbersome).
The second rule does not associate StringHolder to any particular Child
instance (although easily added); so you'd get the cross-product of
StringHolders and Child facts; not I suspect what you'd want.
Cheers,
Mike
On 6 December 2010 10:36, Gabor Szokoli <szocske(a)gmail.com> wrote:
Thanks for the instant response!
2010/12/6 Michael Anstis <michael.anstis(a)gmail.com>:
> 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).
I'm reading the documentation thoroughly of course, but it seems to be
centered about using the system and writing rules. Which is how it
should be, don't get me wrong :-)
I'm just hoping for some spoilers like "Section X will detail how java
object are mapped to WMEs."
> 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).
Can I put off the DSL part for later, and consider it just an extra
layer of rule file parsing for now?
Do I lose the graphical on-line editor features of Guvnor (which I
admittedly have not looked into yet, just salivated over some
screenshots.) if I make a DSL?
> A rather disturbing example you choose to show in your email; I think I
> prefer the "Cheese" centric types in the documentation :)
Other than the attention-whoring double take in nomenclature, does
that rule pattern look OK?
I'll stick with cheese in the future :-)
Thanks Again!
Gabor Szokoli
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5:03 a.m.
In my experience no-loop is pretty much worthless as it only prevents the most trivial
type of loops (a rule reactivating itself). It provides no help for the most common type
of loop where multiple rules modify the same object and reactivate each other.
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On
Behalf Of Michael Anstis
Sent: 06 December 2010 10:54
To: Rules Users List
Subject: Re: [rules-users] new to Drools: modeling issues
Glad you're reading the documents - you'd be surprised how many people asking
questions do not!
You can put off DSL until you're happy your rules are working, off course - in fact,
IMO, it's easier to "debug" rules without the additional abstraction.
You're first rule looks better - although I'd still be inclined to look at no-loop
rather than the check yourself (what if you need the new value to be dynamic; i.e. not
just statically "value"? Your rules would become cumbersome).
The second rule does not associate StringHolder to any particular Child instance (although
easily added); so you'd get the cross-product of StringHolders and Child facts; not I
suspect what you'd want.
Cheers,
Mike
On 6 December 2010 10:36, Gabor Szokoli
<szocske@gmail.com<mailto:szocske@gmail.com>> wrote:
Thanks for the instant response!
2010/12/6 Michael Anstis
<michael.anstis@gmail.com<mailto:michael.anstis@gmail.com>>:
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).
I'm reading the documentation thoroughly of course, but it
seems to be
centered about using the system and writing rules. Which is how it
should be, don't get me wrong :-)
I'm just hoping for some spoilers like "Section X will detail how java
object are mapped to WMEs."
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).
Can I put off the DSL
part for later, and consider it just an extra
layer of rule file parsing for now?
Do I lose the graphical on-line editor features of Guvnor (which I
admittedly have not looked into yet, just salivated over some
screenshots.) if I make a DSL?
A rather disturbing example you choose to show in your email; I think
I
prefer the "Cheese" centric types in the documentation :)
Other than the
attention-whoring double take in nomenclature, does
that rule pattern look OK?
I'll stick with cheese in the future :-)
Thanks Again!
Gabor Szokoli
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
________________________________
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received
this message in error, please immediately notify the postmaster(a)nds.com and delete it from
your system as well as any copies. The content of e-mails as well as traffic data may be
monitored by NDS for employment and security purposes. To protect the environment please
do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United
Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603
8808 40-00
**************************************************************************************
7:22 a.m.
Hi again,
thanks again!
2010/12/6 Swindells, Thomas <TSwindells(a)nds.com>:
In my experience no-loop is pretty much worthless as it only prevents
the
most trivial type of loops (a rule reactivating itself). It provides no
help for the most common type of loop where multiple rules modify the same
object and reactivate each other.
That's why I'm trying to establish the idiom of testing for the
opposite of the "modify" action result.
As long as the modify action is idempotent, I should be OK.
I'm secretly hoping I'll be able to automate this in the DSL later on,
albeit the lack of reflection in "modify" is troubling.
(making the attributes public is always an option, just not nice.)
From: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Michael Anstis
Glad you're reading the documents - you'd be surprised how
many people
asking questions do not!
Well, I have not finished them all either :-)
You can put off DSL until you're happy your rules are working,
off course -
in fact, IMO, it's easier to "debug" rules without the additional
abstraction.
You're first rule looks better - although I'd still be inclined to look at
no-loop rather than the check yourself (what if you need the new value to be
dynamic; i.e. not just statically "value"? Your rules would become
cumbersome).
I'd extract it to be the last term of the condition, and muse under my
beard how the rule engine should allow me to use the same syntax in
"modify", and do the check automatically:
modifyAttribute($object.attribute) { ... }
I understand this can't work for people doing procedural stuff, side
effects, non-trivial setters, etc, but I sure would love it, and they
can just not use it :-)
The second rule does not associate StringHolder to any particular
Child
instance (although easily added); so you'd get the cross-product of
StringHolders and Child facts; not I suspect what you'd want.
Ahh, the dog ate my equals sign:
<<<
$attribute : StringHolder(get()!="value")
$child: Child(parent==$parent ... attribute==$attribute)
>>
But the real question here is how I can make Drools treat my
attributes as the atomic unit of "fact" instead of objects?
Will I be able to cover up this added level of indirection with a DSL?
Gabor Szokoli
9:12 a.m.
+1
GreG
On Dec 6, 2010, at 5:03, "Swindells, Thomas" <TSwindells(a)nds.com> wrote:
In my experience no-loop is pretty much worthless as it only prevents
the most trivial type of loops (a rule reactivating itself). It provides no help for the
most common type of loop where multiple rules modify the same object and reactivate each
other.
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On
Behalf Of Michael Anstis
Sent: 06 December 2010 10:54
To: Rules Users List
Subject: Re: [rules-users] new to Drools: modeling issues
Glad you're reading the documents - you'd be surprised how many people asking
questions do not!
You can put off DSL until you're happy your rules are working, off course - in fact,
IMO, it's easier to "debug" rules without the additional abstraction.
You're first rule looks better - although I'd still be inclined to look at
no-loop rather than the check yourself (what if you need the new value to be dynamic; i.e.
not just statically "value"? Your rules would become cumbersome).
The second rule does not associate StringHolder to any particular Child instance
(although easily added); so you'd get the cross-product of StringHolders and Child
facts; not I suspect what you'd want.
Cheers,
Mike
On 6 December 2010 10:36, Gabor Szokoli <szocske(a)gmail.com> wrote:
Thanks for the instant response!
2010/12/6 Michael Anstis <michael.anstis(a)gmail.com>:
> 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).
I'm reading the documentation thoroughly of course, but it seems to be
centered about using the system and writing rules. Which is how it
should be, don't get me wrong :-)
I'm just hoping for some spoilers like "Section X will detail how java
object are mapped to WMEs."
> 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).
Can I put off the DSL part for later, and consider it just an extra
layer of rule file parsing for now?
Do I lose the graphical on-line editor features of Guvnor (which I
admittedly have not looked into yet, just salivated over some
screenshots.) if I make a DSL?
> A rather disturbing example you choose to show in your email; I think I
> prefer the "Cheese" centric types in the documentation :)
Other than the attention-whoring double take in nomenclature, does
that rule pattern look OK?
I'll stick with cheese in the future :-)
Thanks Again!
Gabor Szokoli
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received
this message in error, please immediately notify the postmaster(a)nds.com and delete it from
your system as well as any copies. The content of e-mails as well as traffic data may be
monitored by NDS for employment and security purposes. To protect the environment please
do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United
Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603
8808 40-00
**************************************************************************************
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5104
days inactive
5104
days old
6 comments
4 participants
participants (4)
-
Gabor Szokoli -
Greg Barton -
Michael Anstis -
Swindells, Thomas