The syntax of what goes in the templates is dependent on if it is a CONDITION column or ACTION column. In most cases, it is identical to vanilla DRL for the LHS or RHS respectively. This means in the LHS, the constraint language must be used, and in the RHS it is a snippet of code to be executed.
The $param
place holder is used in templates to
indicate where data form the cell will be interpolated. You can also use
$1
to the same effect. If the cell contains a comma
separated list of values, $1 and $2 etc. may be used to indicate which
positional parameter from the list of values in the cell will be
used.
Example 3.1.
If the templates is [Foo(bar == $param)] and the cell is [ 42 ] then the result will be [Foo(bar == 42)] If the template is [Foo(bar < $1, baz == $2)] and the cell is [42,42] then the result will be [Foo(bar > 42, baz ==42)]
For conditions: How snippets are rendered depends on if there is
anything in the row above (where ObjectType declarations may appear). If
there is, then the snippets are rendered as individual constraints on
that ObjectType. If there isn't, then they are just rendered as is (with
values substituted). If just a plain field is entered (as in the example
above) then it will assume this means equality. If another operator is
placed at the end of the snippet, then the values will put interpolated
at the end of the constraint, otherwise it will look for
$param
as outlined previously.
For consequences: How snippets are rendered also depends on if there is anything in the row immediately above it. If there is nothing there, the output is simple the interpolated snippets. If there is something there (which would typically be a bound variable or a global like in the example above) then it will append it as a method call on that object (refer to the above example).
This may be easiest to understand with some examples below.
The above shows how the Person ObjectType declaration spans 2 columns in the spreadsheet, thus both constraints will appear as Person(age == ... , type == ...). As before, as only the field names are present in the snippet, they imply an equality test.
The above condition example shows how you use interpolation to place the values in the snippet (in this case it would result in Person(age == "42")).
The above condition example show that if you put an operator on the end by itself, the values will be placed after the operator automatically.
A binding can be put in before the column (the constraints will be added from the cells below). Anything can be placed in the ObjectType row (eg it could be a pre condition for the columns in the spreadsheet columns that follow).
This shows how the consequence could be done the by simple interpolation (just leave the cell above blank, the same applies to condition columns). With this style anything can be placed in the consequence (not just one method call).
The following table describes the keywords that are pertinent to the rule table structure.
Table 3.1. Keywords
Keyword | Description | Inclusion Status |
---|---|---|
RuleSet | The cell to the right of this contains the ruleset name | One only (if left out, it will default) |
Sequential | The cell to the right of this can be true or false. If true, then salience is used to ensure that rules fire from the top down | optional |
Import | The cell to the right contains a comma separated list of Java classes to import | optional |
RuleTable | A cell starting with RuleTable indicates the start of a definition of a rule table. The actual rule table starts the next row down. The rule table is read left-to-right, and top-down, until there is one BLANK ROW. | at least one. if there are more, then they are all added to the one ruleset |
CONDITION | Indicates that this column will be for rule conditions | At least one per rule table |
ACTION | Indicates that this column will be for rule consequences | At least one per rule table |
PRIORITY | Indicates that this columns values will set the 'salience' values for the rule row. Over-rides the 'Sequential' flag. | optional |
DURATION | Indicates that this columns values will set the duration values for the rule row. | optional |
NAME | Indicates that this columns values will set the name for the rule generated from that row | optional |
Functions | The cell immediately to the right can contain functions which can be used in the rule snippets. Drools supports functions defined in the DRL, allowing logic to be embedded in the rule, and changed without hard coding, use with care. Same syntax as regular DRL. | optional |
Variables | The cell immediately to the right can contain global declarations which Drools supports. This is a type, followed by a variable name. (if multiple variables are needed, comma separate them). | optional |
No-loop or Unloop | Placed in the header of a table, no-loop or unloop will both complete the same function of not allowing a rule (row) to loop. For this option to function correctly, there must be a value (true or false) in the cell for the option to take effect. If the cell is left blank then this option will not be set for the row. | optional |
XOR-GROUP | Cell values in this column mean that the rule-row belongs to the given XOR/activation group . An Activation group means that only one rule in the named group will fire (ie the first one to fire cancels the other rules activations). | optional |
AGENDA-GROUP | Cell values in this column mean that the rule-row belongs to the given agenda group (that is one way of controlling flow between groups of rules - see also "rule flow"). | optional |
RULEFLOW-GROUP | Cell values in this column mean that the rule-row belongs to the given rule-flow group. | optional |
Worksheet | By default, the first worksheet is only looked at for decision tables. | N/A |
Below you will find examples of using the HEADER keywords, which effects the rules generated for each row. Note that the header name is what is important in most cases. If no value appears in the cells below it, then the attribute will not apply (it will be ignored) for that specific row.
The following is an example of Import (comma delimited), Variables (gloabls) - also comma delimited, and a function block (can be multiple functions - just the usual drl syntax). This can appear in the same column as the "RuleSet" keyword, and can be below all the rule rows if you desire.