[rules-users] Non short circuit ANDing

[Stephen Masters]

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.

A tracking working memory event listener:
https://github.com/gratiartis/sctrcd-fx-web/blob/master/src/main/java/uk/co/scattercode/drools/util/TrackingWorkingMemoryEventListener.java
Attach it to your session to keep track of all facts as they are inserted/updated/retracted. It also supports filtering for fact classes or handles so that you can pick out which ones are relevant.

A tracking agenda event listener:
https://github.com/gratiartis/sctrcd-fx-web/blob/master/src/main/java/uk/co/scattercode/drools/util/TrackingAgendaEventListener.java
Keeps track of and logs every rule which fires.

I use them in this test helper class, which enables me to create unit tests which assert that specific rules have fired or that specific facts are in working memory.
https://github.com/gratiartis/sctrcd-fx-web/blob/master/src/main/java/uk/co/scattercode/drools/util/DroolsTestUtil.java


Between those, you should be able to knock up something which does an appropriate audit of what's going on in your rules without refactoring any of your DRL. I prefer using listeners like this to monitor what's going on, as they don't intrude on your code. I tend to think that the rules should be simple and specific to the decision being made, rather than needing them to be written in a specific way in order to achieve some side effects.

Steve



On 31 Jan 2013, at 00:53, Davide Sottara <dsotty at gmail.com> wrote:

> Gents, 
> this is a really interesting discussion and I wish I had more time to participate.. I agree with Stephen that some constraints are really worthy monitoring, 
> while others are simply "filters".. Wolfgang's mention of "near misses" is potentially a hot topic, I have been experimenting with "imperfect" rules which
> are more robust in that sense and provide better traceability, but that is not yet implemented in the core engine. 
> I would also point out that one thing is monitor constraints for "logging" or "auditing" purposes, another is the ability to specify different behaviours
> (i.e. consequences) according to the success vs failure of an evaluation. 
> To this end, and following on the "extending" rule thread, it has actually been planned and partially implemented.. it's only an experimental feature
> (@Mario, any update/clarification?), so it's probably not well documented. But I would point you to these links:
> 
> http://blog.athico.com/2012/09/conditional-branches-with-sub-blocks.html
> 
> https://community.jboss.org/wiki/BranchCEs
> 
> with the warning that it's still experimental and, while adopting "familiar" keywords (if, then, else, switch), their semantics is different from the 
> usual imperative language one, and in fact could enable some of the "extend" capabilities that have been invoked in the last couple of posts.
> 
> Best
> Davide
> 
> 
> On 01/30/2013 02:25 PM, Cotton, Ben wrote:
>> 
>> 
>> Ø automatically rename each rule "part" (being a single-condition rule derived from the original) to some derivation of the original rule name, and need the consequence only in the fully-extended rule, thereby giving the same effect, but with rule "parts" that would reflect failure at the             individual condition level
>> 
>> This is *exactly* the ambition we are hoping that some Drools .DRL enrichment tool (or other Drools capability) can provide. 
>>  
>> Wish I had sufficient competency to comment on the merits of your different suggested approaches.  Hopeful that the Drools gurus will comment explicitly on all these approaches (and/or the approach suggested by another of using Working Memory listeners).
>>  
>>  
> _______________________________________________
> 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/20130131/c2fbbac8/attachment.html