Chapter 3. The Rule Language - JBoss RULES 4.0.0.11754MR2 manual 英文版使用指南文档

A rule file is typically a file with a .drl extension. In a drl file you can have multiple rules, functions etc. However, you are also able to spread your rules across multiple rule files (in that case, the extension .rule is suggested, but not required) - spreading rules across files can help with managing large numbers of rules. A DRL file is simply a text file.

A rule has the following rough structure:

Its really that simple. Mostly punctuation is not needed, even the double quotes for "name" are optional, as are newlines. ATTRIBUTES are simple (always optional) hints to how the rule should behave. LHS is the conditional parts of the rule, which follows a certain syntax which is covered below. RHS is basically a block that allows Java semantic code to be executed (this will soon support other semantic languages, like groovy, and C#). The only special keywords here are for asserting, retracting or modifying facts. Any variables bound in the LHS are available here.

It is important to note that whitepace is not important, EXCEPT in thse case of domain specific languages, in which case each line is processed before the following line (and spaces may be significant to the domain language).

Domain specific languages are implemented as an enhancement over the native rule language. They use the "expander" mechanism. The expander mechanism is an extensible API, but by default it can work with .dsl files, which contain mappings from the domain or natural language to the rule language and your domain objects. You can think of these .dsl files also as a mapping to your domain model (which provides you with some insulation). DSLs/expanders work by processing a line in the rule source as it is being compiled - this is the only time that newlines are significant. This is done to aid readability and avoid the need for punctuation. It is expected that over time, alternative expanders and DSLs will be available/prebuilt for various domains, and provide other forms of natural language parsing and analysis. It is up to you if you believe a DSL is of benefit to your application - they certainly make for very nice looking rules, but for some folks, the native rule language is ideal. Freedom is good.

There are some reserved keywords that are used in the rule language. It is wise to avoid collisions with these words when naming your domain objects, properties, methods, functions and so on that are used in the rule text. The following list are words that you should try and avoid in the rule contents if possible (often times it will work fine, but in some cases the rules may be parsed incorrectly). Of course, you can have words as part of a method name in camel case, like notSomething() - there are no issues with that scenario.