Section 10.1.13 says that the rules file for Conway is PetStore.drl.



jb




--
Jeff Brown
Principal Software Engineer
Object Computing Inc.
http://www.ociweb.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

For the case when r2 has the 'not'. When 4 doesn't exist r3 is true, when r3 fires it asserts 4, thus r3 can no longer be true, however r4 retracts the 4 and 2  still exists, thus enabling r3 to match again which causes the recursion - basically the insertion and retracting of 4 is toggling r3 on and off. Best thing to do is always use the audit log so you can visualise what's going on.

Mark
lukichev wrote:

Dear Mark,

 

I have a question concerning rule execution algorithm in JBoss 4.0.1.

 

There are 2 rule sets, one runs in a circle and another one stops.

 

The first one, which stops:

 

rule "r1"

      when

            $num1:Integer(intValue == 1)

      then

            insert(new Integer(2));

end

 

rule "r2"

      when

            $num1:Integer(intValue == 2)

      then

            insert(new Integer(3));

end

 

rule "r3"

      when

            $num1:Integer(intValue == 2)

      then

          insert(new Integer(4));

end

 

rule "r4"

      when

            $num1:Integer(intValue == 3)

            $num2:Integer(intValue == 4)

      then

            retract($num2);

end

 

The second one, which runs in a circle, is different from the one above by the additional condition in r3:

 

            not $num2:Integer(intValue == 4)

 

I would expect the same behavior of these two rule sets, but it is different. Could you, please, comment, why this is so?

 

Sincerely,

Sergey Lukichev

Research Assistant, REWERSE I1, rule modeling and markup

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Folks,

Two general comments on the format of the RuleFlow (.rf) file from when I was doing the NumberGuess documentation.

When I built workflow apps using jBPM I was able to edit the workflow XML files by hand. Some people prefer this and it makes it easier should somebody want to build an alternative editor for these files ( e.g Web Based instead of the Eclipse IDE).  For jBPM I *had* to edit these manually , as the IDE kept crashing.

The comment / complaint is that the Drools Ruleflow files are much harder to edit. Yes, it's xml but the nodes do not seem to be in any particular order. With jBPM , the nodes tend to be arranged in a flow from Start to End.

Talking of Web Based editors for flow, have you seen the Ajax / DHTML Editor that Yahoo has for Pipes: http://firstpartners.net/blog/technology/xml/2007/03/23/yahoo-pipes-in-10-easy-steps-sample-for-iona-dublin/

This shows that it is possible to have a Flow editor implemented in HTML.

Just my two thoughts.

Paul

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Paul Browne wrote:

Folks,

Two general comments on the format of the RuleFlow (.rf) file from when I was doing the NumberGuess documentation.

When I built workflow apps using jBPM I was able to edit the workflow XML files by hand. Some people prefer this and it makes it easier should somebody want to build an alternative editor for these files ( e.g Web Based instead of the Eclipse IDE).  For jBPM I *had* to edit these manually , as the IDE kept crashing.

The comment / complaint is that the Drools Ruleflow files are much harder to edit. Yes, it's xml but the nodes do not seem to be in any particular order. With jBPM , the nodes tend to be arranged in a flow from Start to End.

The XML is not currently meant to be human editable. We have an AST and we just dump that to XML using XStream. The reason for this is the tech is still maturing and we don't want to lock ourselves into supporting a particularly XML format yet. Again once our ruleflow matures we'll look at a simplified XML that we will support a long time.

Talking of Web Based editors for flow, have you seen the Ajax / DHTML Editor that Yahoo has for Pipes: http://firstpartners.net/blog/technology/xml/2007/03/23/yahoo-pipes-in-10-easy-steps-sample-for-iona-dublin/

Yes seen the SVG thing, its a matter of resources, if someone contributes the code we would love to see that :) Maybe once ruleflow matures we can put some resources into this.

This shows that it is possible to have a Flow editor implemented in HTML.

Just my two thoughts.

Paul

On 10/1/07, Mark Proctor <mproctor <at> codehaus.org> wrote:

Feedback welcome.
http://blog.athico.com/2007/10/drools-examples-documentation-gets.html

Mark
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

No problems. Always aware that it's easy to make suggestions , but hard to get the time to actually implement them.

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful.

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev