Hi All, I have a bunch of rules that evaluate using some constant variable (say "slackTicks"). Currently, in my rules, I write down the value of this "slack" each and every time I use it, for example: TransferSchedule( tick > currentTick - 10d ) where 10 is the slack. A solution would be to insert constant facts: Constant( key = "slack", $slackTicks : value ) TransferSchedule( tick > currentTick - $slackTicks ) Or inject a global properties object: global Properties constants $slackTicks : Double.valueOf(constants.getPropertyValue("model.slack", "0")) Or, the last one I can think of: a public final static on the fact class: TransferSchedule( tick > currentTick - TransferSchedule.SLACK_TICKS ) These all cross the boundary between Java and Drools. In my Java code I have to insert the Constant facts or inject the global. When my drools developers think of some new ways to create the rules, I run the risk of having to go in and modify the .properties file or, worse, change the Java code. To be able to define a "constant" would be a clean solution: declare constant double SLACK_TICKS = 10; ... TransferSchedule( tick > currentTick - SLACK_TICKS ) ... This separates the rules from the Java code and give the rules developer all freedom to do whatever they want to make constant. Ah, just thought of another way to do it. You can insert the facts from within Drools itself: declare Constant key : String value : Object end rule initialize salience 100000 when // always then insert( new Constant( "slack", 10d ) ); //... other constants go here end I will still have to "capture" the constants that I need in every rule with a Constants( key == "...", $c : value ) premise, though... And you would need to add some more Constant classes to cater to contain type safety... What's your thought? What strategy do you use? Regards, Willem _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Here's another one for your collection of constant workarounds: function int slackTicks(){ returns 42; } -W On 18/02/2013, Willem van Asperen <willem(a)van.asperen.org&gt; wrote: > Hi All, > > I have a bunch of rules that evaluate using some constant variable (say > "slackTicks"). Currently, in my rules, I write down the value of this > "slack" each and every time I use it, for example: > > |TransferSchedule( tick > currentTick - 10d )| > > where 10 is the slack. > > A solution would be to insert constant facts: > > |Constant( key = "slack", $slackTicks : value )|| > ||TransferSchedule( tick > currentTick - $slackTicks )| > > Or inject a global properties object: > > |global Properties constants|| > || > ||$slackTicks : Double.valueOf(constants.getPropertyValue("model.slack", > "0"))| > > Or, the last one I can think of: a public final static on the fact class: > > |TransferSchedule( tick > currentTick - TransferSchedule.SLACK_TICKS )|| > | > These all cross the boundary between Java and Drools. In my Java code I > have to insert the Constant facts or inject the global. When my drools > developers think of some new ways to create the rules, I run the risk of > having to go in and modify the .properties file or, worse, change the > Java code. > > To be able to define a "constant" would be a clean solution: > > |declare||constant double SLACK_TICKS = 10||; > |||| > ... > ||TransferSchedule( tick > currentTick - SLACK_TICKS )|| > ... > | > This separates the rules from the Java code and give the rules developer > all freedom to do whatever they want to make constant. > > Ah, just thought of another way to do it. You can insert the facts from > within Drools itself: > > |declare Constant|| > || key : String|| > || value : Object|| > ||end|| > || > ||rule initialize|| > || salience 100000|| > || when|| > || // always|| > || then|| > || insert( new Constant( "slack", 10d ) );|| > || //... other constants go here|| > ||end|| > | > I will still have to "capture" the constants that I need in every rule > with a Constants( key == "...", $c : value ) premise, though... And you > would need to add some more Constant classes to cater to contain type > safety... > > What's your thought? What strategy do you use? > > Regards, > Willem >