Ø
On Thu, Jan 31, 2013 at 3:49 AM, Stephen Masters <stephen.masters@me.com> wrote:
Ø
> fyi - if you're just learning your way around working memory event
Ø
> listeners and the like, here's some example code. It's an extended
Ø
> version of something I found in the Drools docs.
Ø
Ø
Cool. Thanks for the code.
Thanks indeed Stephen.
Another very-quick newbie question (sorry if I should have done the work to research the answer myself):
Is it at all possible for listeners, once they have established that a rule has failed, to provide any higher resolution information that could potentially help answer the question “why did this rule fail?”
– e.g. identify the specific L-value predicate participant that failed to match, etc.?
-----Original Message-----
From: rules-users-bounces@lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Grant Rettke
Sent: Thursday, January 31, 2013 10:10 AM
To: Rules Users List
Subject: Re: [rules-users] Non short circuit ANDing
On Thu, Jan 31, 2013 at 3:49 AM, Stephen Masters <stephen.masters@me.com> wrote:
> fyi - if you're just learning your way around working memory event
> listeners and the like, here's some example code. It's an extended
> version of something I found in the Drools docs.
Cool. Thanks for the code.
The discussion has got me curious, here is the conclusion that I had made about rules engines:
1. Start with normal code. Write it in a way that lets you achieve your goal. Performance is not the primary focus. Work with the business do agile. Get all the auditing you want because it is just normal code. Life goes on.
2. Life is good but the performance is too slow. This is where you cut over to a RETE based rules engine.
Does that sound right?
_______________________________________________
rules-users mailing list