[jboss-svn-commits] JBL Code SVN: r19332 - in labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en: Chapter-Rule_Language and 1 other directory.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Mon Mar 31 01:59:54 EDT 2008
Author: irooskov at redhat.com
Date: 2008-03-31 01:59:54 -0400 (Mon, 31 Mar 2008)
New Revision: 19332
Modified:
labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Engine/Section-Rete_Algorithm.xml
labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Engine/Section-Rules.xml
labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml
labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Comments.xml
labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Function.xml
labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Overview.xml
labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Package.xml
labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Rule.xml
Log:
Updated the reference guide with changes
Modified: labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Engine/Section-Rete_Algorithm.xml
===================================================================
--- labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Engine/Section-Rete_Algorithm.xml 2008-03-31 04:11:22 UTC (rev 19331)
+++ labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Engine/Section-Rete_Algorithm.xml 2008-03-31 05:59:54 UTC (rev 19332)
@@ -8,7 +8,7 @@
his PhD thesis in 1978-79. A simplified version of the paper was published
in 1982 (<ulink
url="http://citeseer.ist.psu.edu/context/505087/0">http://citeseer.ist.psu.edu/context/505087/0</ulink>).
- The word RETE is latin for "net" meaning network. The RETE algorithm can be broken
+ The word RETE is latin for <emphasis>net</emphasis> meaning network. The RETE algorithm can be broken
into 2 parts: rule compilation and runtime execution.</para>
<para>The compilation algorithm describes how the Rules in the Production
@@ -33,7 +33,7 @@
<para>The root node is where all objects enter the network. From there, it
immediately goes to the ObjectTypeNode. The purpose of the ObjectTypeNode is
to make sure the engine doesn't do more work than it needs to. For example,
- say we have 2 objects: Account and Order. If the rule engine tried to
+ say there are 2 objects: Account and Order. If the rule engine tried to
evaluate every single node against every object, it would waste a lot of
cycles. To make things efficient, the engine should only pass the object to
the nodes that match the object type. The easiest way to do this is to
@@ -80,25 +80,24 @@
<para>Drools extends Rete by optimizing the propagation from ObjectTypeNode
to AlphaNode using hashing. Each time an AlphaNode is added to an
ObjectTypeNode it adds the literal value as a key to the HashMap with the
- AlphaNode as the value. When a new instance enters the ObjectType node,
- rather than propagating to each AlphaNode, it can instead retrieve the
- correct AlphaNode from the HashMap - avoiding unnecessary literal
+ AlphaNode as the value. When a new instance enters the ObjectType node
+ (rather than propagating to each AlphaNode), it can retrieve the
+ correct AlphaNode from the HashMap; avoiding unnecessary literal
checks.</para>
- <para>There are two two-input nodes; JoinNode and NotNode - both are
+ <para>There are two dual input nodes, JoinNode and NotNode; both are
types of BetaNodes. BetaNodes are use to compare 2 objects, and their
fields, to each other. The objects may be the same or different types. By
convention we refer to the two inputs as left and right. The left input for
a BetaNode is generally a list of objects; in Drools this is a Tuple. The
- right input is a single object. Two Nodes can be used to implement 'exists'
+ right input is a single object. Two Nodes can be used to implement <emphasis>exists</emphasis>
checks. BetaNodes also have memory. The left input is called the Beta Memory
and remembers all incoming tuples. The right input is called the Alpha
Memory and remembers all incoming objects. Drools extends Rete by
performing indexing on the BetaNodes. For instance, if we know that a
- BetaNode is performing a check on a String field, as each object enters we
- can do a hash lookup on that String value. This means when facts enter from
+ BetaNode is performing a check on a String field, as each object enters a hash lookup can be performed on that String value. This means when facts enter from
the opposite side, instead of iterating over all the facts to find valid
- joins, we do a lookup returning potentially valid candidates. At any
+ joins, a lookup is done, returning potentially valid candidates. At any
point if a valid join is found the Tuple is joined with the Object; which is
referred to as a partial match; and then propagated to the next node.</para>
@@ -113,43 +112,43 @@
</figure>
<para>To enable the first Object (in the above case this is Cheese) to enter the
- network we use a LeftInputNodeAdapter - this takes an Object as an input and
+ network a LeftInputNodeAdapter is used. This takes an Object as an input and
propagates a single Object Tuple.</para>
<para>Terminal nodes are used to indicate a single rule has matched all its
- conditions - at this point we say the rule has a full match. A rule with an
- 'or' conditional disjunctive connective results in subrule generation for
+ conditions. At this point it is said that the rule has a full match. A rule with an
+ <emphasis>or</emphasis> conditional disjunctive connective results in subrule generation for
each possible logically branch; thus one rule can have multiple terminal
nodes.</para>
<para>Drools also performs node sharing. Many rules repeat the same
- patterns, node sharing allows us to collapse those patterns so that they
+ patterns, node sharing allows for the collapse of those patterns so that they
don't have to be re-evaluated for every single instance. The following two
rules share the same first pattern, but not the last:</para>
- <programlisting>
- <![CDATA[
- rule
- when
- Cheese( $chedddar : name == "cheddar" )
- $person : Person( favouriteCheese == $cheddar )
- then
- System.out.println( $person.getName() + " likes cheddar" );
- end
- ]]>
- </programlisting>
+<screen>
+<![CDATA[
+rule
+when
+ Cheese( $chedddar : name == "cheddar" )
+ $person : Person( favouriteCheese == $cheddar )
+then
+ System.out.println( $person.getName() + " likes cheddar" );
+end
+]]>
+</screen>
- <programlisting>
- <![CDATA[
- rule
- when
- Cheese( $chedddar : name == "cheddar" )
- $person : Person( favouriteCheese != $cheddar )
- then
- System.out.println( $person.getName() + " does not like cheddar" );
- end
- ]]>
- </programlisting>
+<screen>
+<![CDATA[
+rule
+when
+ Cheese( $chedddar : name == "cheddar" )
+ $person : Person( favouriteCheese != $cheddar )
+then
+ System.out.println( $person.getName() + " does not like cheddar" );
+end
+]]>
+</screen>
<para>As you can see below, the compiled Rete network shows the alpha node is
shared, but the beta nodes are not. Each beta node has its own TerminalNode. Had
Modified: labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Engine/Section-Rules.xml
===================================================================
--- labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Engine/Section-Rules.xml 2008-03-31 04:11:22 UTC (rev 19331)
+++ labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Engine/Section-Rules.xml 2008-03-31 05:59:54 UTC (rev 19332)
@@ -207,29 +207,29 @@
extends Propositional Logic. <ulink
url="http://en.wikipedia.org/wiki/Emil_Leon_Post">Emil Leon Post</ulink>
was the first to develop an inference based system using symbols to
- express logic - as a consequence of this he was able to prove that any
+ express logic. As a consequence of this he was able to prove that any
logical system (including mathematics) could be expressed with such a
system.</para>
<para>A proposition is a statement that can be classified as true or
false. If the truth can be determined from statement alone it is said to
- be a "closed statement". In programming terms this is an expression that
+ be a <emphasis>closed statement</emphasis>. In programming terms this is an expression that
does not reference any variables:</para>
<para>10 == 2 * 5</para>
<para>Expressions that evaluate against one or more variables, the facts,
- are "open statements", in that we cannot determine whether the statement
- is true until we have a variable instance to evaluate against:</para>
+ are <emphasis>open statements</emphasis>, in that it cannot be determined whether the statement
+ is true until there is a variable instance to evaluate against:</para>
<para>Person.sex == "male"</para>
- <para>With SQL if we look at the conclusion's action as simply returning
+ <para>With SQL if we look at the conclusions action as simply returning
the matched fact to the user:</para>
<para>select * from People where People.sex == "male"</para>
- <para>For any rows, which represent our facts, that are returned we have
+ <para>For any rows, which represent the facts, that are returned, it is
inferred that those facts are male people. The following diagram shows how
the above SQL statement and People table can be represented in terms of an
Inference Engine.</para>
@@ -245,88 +245,91 @@
</figure>
<para>So in Java we can say that a simple proposition is of the form
- 'variable' 'operator' 'value' - where we often refer to 'value' as being a
- literal value - a proposition can be thought as a field constraint.
- Further to this, propositions can be combined with conjunctive and
+ <emphasis>variable operator value</emphasis>; where <emphasis>value</emphasis> is often refered to as being a
+ literal value. A proposition can be thought as a field constraint and can
+ be combined with conjunctive and
disjunctive connectives, which is the logic theorists way of saying
'&&'(and) and '||' (or). The following shows two open propositional
statements connected together with a single disjunctive connective.</para>
- <programlisting>
+<screen>
- person.getEyeColor().equals("blue") || person.getEyeColor().equals("green")
+person.getEyeColor().equals("blue") || person.getEyeColor().equals("green")
- </programlisting>
+</screen>
<para>This can be expressed using a disjunctive Conditional Element
connective - which actually results in the generation of two rules, to
represent the two possible logic outcomes.</para>
- <programlisting>
+<screen>
- Person( eyeColour == "blue" ) || Person( eyeColor == "green" )
+Person( eyeColour == "blue" ) || Person( eyeColor == "green" )
- </programlisting>
+</screen>
<para>Disjunctive field constraints connectives could also be used and
would not result in multiple rule generation.</para>
- <programlisting>
+<screen>
- Person( eyeColour == "blue"||"green" )
+Person( eyeColour == "blue"||"green" )
- </programlisting>
+</screen>
- <para>Propositional Logic is not Turing complete, limiting the problems
- you can define, because it cannot express criteria for the structure of
+ <para>Propositional Logic is not Turing complete, limiting the problems that can be defined, because it cannot express criteria for the structure of
data. First Order Logic (FOL), or Predicate Logic, extends Propositional
Logic with two new quantifier concepts to allow expressions defining
- structure - specifically universal and existential quantifiers. Universal
- quantifiers allow you to check that something is true for everything;
- normally supported by the 'forall' conditional element. Existential
+ structure; specifically universal and existential quantifiers. Universal
+ quantifiers allow for the checking that something is true for everything;
+ normally supported by the <emphasis>forall</emphasis> conditional element. Existential
quantifiers check for the existence of something, in that it occurs at
- least once - this is supported with 'not' and 'exists' conditional
+ least once, which is supported with <emphasis>not</emphasis> and <emphasis>exists</emphasis> conditional
elements.</para>
- <para>Imagine we have two classes - Student and Module. Module represents
+ <para>As an example, there are two classes, Student and Module. Module represents
each of the courses the Student attended for that semester, referenced by
the List collection. At the end of the semester each Module has a score.
If the Student has a Module score below 40 then they will fail that
- semester - the existential quantifier can be used with the "less than
- 40" open proposition to check for the existence of a Module that is true
+ semester. The existential quantifier can be used with the <emphasis>less than
+ 40</emphasis> open proposition to check for the existence of a Module that is true
for the specified criteria.</para>
- <programlisting>
+<screen>
- public class Student {
- private String name;
- private List modules;
+public class Student
+{
- ...
- }
+private String name;
+private List modules;
+
+}
- </programlisting>
+</screen>
- <programlisting>
+<para></para>
+
+<screen>
- public class Module {
- private String name;
- private String studentName;
- private int score;
-
- }
- </programlisting>
+public class Module
+{
- <para>Java is Turing complete in that you can write code, among other
- things, to iterate data structures to check for existence. The following
+private String name;
+private String studentName;
+private int score;
+
+}
+</screen>
+
+ <para>Java is Turing complete in that code can be written to iterate data structures to check for existence. The following
should return a List of students who have failed the semester.</para>
- <programlisting>
+<screen>
- List failedStudents = new ArrayList();
+List failedStudents = new ArrayList();
- for ( Iterator studentIter = students.iterator(); studentIter.hasNext() {
- Student student = ( Student ) studentIter.next();
+for ( Iterator studentIter = students.iterator(); studentIter.hasNext() {
+ Student student = ( Student ) studentIter.next();
for ( Iterator it = student.getModules.iterator(); it.hasNext(); ) {
Module module = ( Module ) it.next();
if ( module.getScore() < 40 ) {
@@ -334,9 +337,8 @@
break;
}
}
- }
-
- </programlisting>
+}
+</screen>
<para>Early SQL implementations were not Turing complete as they did not
provide quantifiers to access the structure of data. Modern SQL engines do
@@ -344,7 +346,7 @@
and 'in'. The following show SQL and a Rule to return a set of Students
who have failed the semester.</para>
- <programlisting>
+<screen>
select
*
@@ -359,18 +361,16 @@
m.student_name = s.name and
m.score < 40
)
+</screen>
- </programlisting>
-
<para></para>
- <programlisting>
+<screen>
- rule "Failed_Students"
- when
- exists( $student : Student() && Module( student == $student, score < 40 ) )
-
- </programlisting>
+rule "Failed_Students"
+when
+ exists( $student : Student() && Module( student == $student, score < 40 ) )
+</screen>
<para></para>
</section>
Modified: labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml
===================================================================
--- labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml 2008-03-31 04:11:22 UTC (rev 19331)
+++ labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml 2008-03-31 05:59:54 UTC (rev 19332)
@@ -8,7 +8,7 @@
<orderedlist>
<listitem>
- <para>When should you use a rule engine?</para>
+ <para>When should a rule engine be used?</para>
</listitem>
<listitem>
@@ -17,7 +17,7 @@
</listitem>
<listitem>
- <para>Why should you use a rule engine instead of a scripting framework,
+ <para>Why should a rule engine be used instead of a scripting framework,
like <indexterm>
<primary>BeanShell</primary>
</indexterm> BeanShell?</para>
@@ -33,7 +33,7 @@
<listitem>
<para>Declarative Programming</para>
- <para>Rule engines allow you to say "What to do" not "How to do
+ <para>Rule engines allow for the defining of "What to do" instead of "How to do
it".</para>
<para>The key advantage of this point is that using rules can make it
@@ -44,16 +44,15 @@
<para>Rule systems are capable of solving very, very hard problems,
providing an explanation of how the solution was arrived at and why
each "decision" along the way was made (not so easy with other AI
- systems like neural networks or the human brain).</para>
+ systems such as neural networks or the human brain).</para>
</listitem>
<listitem>
<para>Logic and Data Separation</para>
- <para>Your data is in your domain objects, the logic is in the rules.
- This is fundamentally breaking the OO coupling of data and logic,
- which can be an advantage or a disadvantage depending on your point of
- view. The upshot is that the logic can be much easier to maintain as
+ <para>The data is in the domain objects, the logic is in the rules.
+ This is fundamentally breaking the Object Orientated (OO) coupling of data and logic,
+ which can be an advantage or a disadvantage depending on the situation. The upshot is that the logic can be much easier to maintain as
there are changes in the future, as the logic is all laid out in
rules. This can be especially true if the logic is cross-domain or
multi-domain logic. Instead of the logic being spread across many
@@ -66,8 +65,8 @@
<para>The Rete algorithm, and its descendants such as
Drools' ReteOO, provide very efficient ways of matching
- rule patterns to your domain object data. These are especially
- efficient when you have datasets that do not change entirely (as the
+ rule patterns to domain object data. These are especially
+ efficient when there are datasets that do not change entirely (as the
rule engine can remember past matches). These algorithms are battle
proven.</para>
</listitem>
@@ -75,7 +74,7 @@
<listitem>
<para>Centralization of Knowledge</para>
- <para>By using rules, you create a repository of knowledge (a
+ <para>By using rules, a repository of knowledge is created (a
knowledge base) which is executable. This means it's a single point of
truth, for business policy (for instance) - ideally rules are so
readable that they can also serve as documentation.</para>
@@ -84,7 +83,7 @@
<listitem>
<para>Tool Integration</para>
- <para>Tools such as Eclipse (and in the future, Web based User Interfaces) provide
+ <para>Tools such as Eclipse provide
ways to edit and manage rules and get immediate feedback, validation
and content assistance. Auditing and debugging tools are also
available.</para>
@@ -93,7 +92,7 @@
<listitem>
<para>Explanation Facility</para>
- <para>Rule systems effectively provide an "explanation facility" by
+ <para>Rule systems effectively provide an <emphasis>explanation facility</emphasis> by
being able to log the decisions made by the rule engine along with why
the decisions were made.</para>
</listitem>
@@ -102,27 +101,26 @@
<para>Understandable Rules</para>
<para>By creating object models and, optionally, Domain Specific
- Languages that model your problem domain you can set yourself up to
- write rules that are very close to natural language. They lend
+ Languages that model your problem domain rules can be written that are very close to natural language. They lend
themselves to logic that is understandable to, possibly nontechnical,
domain experts as they are expressed in their language (all the
- program plumbing, the "How", is in the usual code, hidden
+ program plumbing, the <emphasis>How</emphasis>, is in the usual code, hidden
away).</para>
</listitem>
</itemizedlist>
</section>
<section>
- <title>When should you use a Rule Engine?</title>
+ <title>When should a Rule Engine be used?</title>
<para>The shortest answer to this is "when there is no satisfactory
traditional programming approach to solve the problem.". Given that short
answer, some more explanation is required. The reason why there is no
- "traditional" approach is possibly one of the following: <itemizedlist>
+ <emphasis>traditional</emphasis> approach is possibly one of the following: <itemizedlist>
<listitem>
<para>The problem is just too fiddly for traditional code.</para>
- <para>The problem may not be complex, but you can't see a
+ <para>The problem may not be complex, but there is no
non-fragile way of building it.</para>
</listitem>
@@ -141,7 +139,7 @@
<para>The logic itself may be simple (but doesn't have to be) but
the rules change quite often. In many organizations software
releases are few and far between and rules can help provide the
- "agility" that is needed and expected in a reasonably safe
+ <emphasis>agility</emphasis> that is needed and expected in a reasonably safe
way.</para>
</listitem>
@@ -155,39 +153,34 @@
terms. Of course, they still have to think critically and be capable
of logical thinking (many people in "soft" nontechnical positions do
not have training in formal logic, so be careful and work with them,
- as by codifying business knowledge in rules, you will often expose
- holes in the way the business rules and processes are currently
+ as by codifying business knowledge in rules, holes will often be exposed in the way the business rules and processes are currently
understood).</para>
</listitem>
</itemizedlist></para>
- <para>If rules are a new technology for your project teams, the overhead
+ <para>If rules are a new technology for current project teams, the overhead
in getting going must be factored in. Its not a trivial technology, but
this document tries to make it easier to understand.</para>
- <para>Typically in a modern OO application you would use a rule engine to
- contain key parts of your business logic (what that means of course
- depends on the application) - ESPECIALLY the REALLY MESSY parts!. This is
- an inversion of the OO concept of encapsulating all the logic inside your
- objects. This is not to say that you throw out OO practices, on the
- contrary in any real world application, business logic is just one part of
- the application. If you ever notice lots of "if", "else", "switch", an
- over abundance of strategy patterns and/or other messy logic in your code
- that just doesn't feel right (and you keep coming back to fix it - either
- because you got it wrong, or the logic/your understanding changes) - think
- about using rules. If you are faced with tough problems of which there are
+ <para>Typically in a modern OO application a rule engine would be used to
+ contain key parts of the business logic (what that means of course
+ depends on the application). This is
+ an inversion of the OO concept of encapsulating all the logic inside the
+ objects. In real world application, business logic is just one part of
+ the application. If many of "if", "else", "switch", an
+ over abundance of strategy patterns and/or other messy logic are in your code (and they are constantly requiring maintanance), think
+ about using rules. When faced with tough problems of which there are
no algorithms or patterns for, consider using rules.</para>
- <para>Rules could be used embedded in your application or perhaps as a
- service. Often rules work best as "stateful" components - hence they are
+ <para>Rules can be embedded into an application or perhaps as a
+ service. Often rules work best as <emphasis>stateful</emphasis> components, hence they are
often an integral part of an application. However, there have been
successful cases of creating reusable rule services which are
stateless.</para>
- <para>In your organization it is important to think about the process you
- will use for updating rules in systems that are in production (the options
- are many, but different organizations have different requirements - often
- they are out of the control of the application vendors/project
+ <para>In an organization it is important to think about the processes to be used for updating rules in systems that are in production (the options
+ are many, but different organizations have different requirements. Often
+ they are out of the control of the application vendors or project
teams).</para>
</section>
@@ -205,11 +198,9 @@
<para>As rule engines are dynamic (dynamic in the sense that the rules can
be stored, managed and updated as data), they are often looked at as a
- solution to the problem of deploying software (most IT departments seem to
- exist for the purpose of preventing software being rolled out). If this is
- the reason you wish to use a rule engine, be aware that rule engines work
- best when you are able to write declarative rules. As an alternative, you
- can consider data-driven designs (lookup tables), or script/process
+ solution to the problem of deploying software. If this is
+ the reason for using a rule engine, be aware that rule engines work
+ best when declarative rules can be written. As an alternative, consider data-driven designs (lookup tables), or script/process
engines where the scripts are managed in a database and are able to be
updated on the fly.</para>
</section>
@@ -217,30 +208,29 @@
<section>
<title>Scripting or Process Engines</title>
- <para>Hopefully the preceding sections have explained when you may want to
+ <para>Hopefully the preceding sections have explained when to
use a rule engine.</para>
<para>Alternatives are script-based engines that provide the dynamicness
for "changes on the fly" (there are many solutions here).</para>
<para>Alternatively, Process Engines (also capable of workflow) such as
- jBPM allow you to graphically (or programmatically) describe steps in a
- process - those steps can also involve decision points which are in
+ jBPM allow a user to graphically (or programmatically) describe steps in a
+ process. The steps can also involve decision points which are in
themselves a simple rule. Process engines and rules often can work nicely
together, so it is not an either-or proposition.</para>
<para>One key point to note with rule engines, is that some rule-engines
are really scripting engines. The downside of scripting engines is that
- you are tightly coupling your application to the scripts (if they are
- rules, you are effectively calling rules directly) and this may cause more
+ the application becomes tightly coupling to the scripts (if they are
+ rules, they are effectively being called directly) and this may cause more
difficulty in future maintenance, as they tend to grow in complexity over
- time. The upside of scripting engines is they can be easier to implement
- at first, and you can get quick results (and conceptually simpler for
- imperative programmers!).</para>
+ time. The upside of scripting engines is that they can be easier to implement
+ at first, with quick results (and conceptually simpler for programmers).</para>
<para>Many people have also implemented data-driven systems successfully
in the past (where there are control tables that store meta-data that
- changes your applications behavior) - these can work well when the
+ changes your applications behavior). These can work well when the
control can remain very limited. However, they can quickly grow out of
control if extended to much (such that only the original creators can
change the applications behavior) or they cause the application to
@@ -250,19 +240,19 @@
<section>
<title>Strong and Loose Coupling</title>
- <para>No doubt you have heard terms like "tight coupling" and "loose
- coupling" in systems design. Generally people assert that "loose" or
- "weak" coupling is preferable in design terms, due to the added
- flexibility it affords. Similarly, you can have "strongly coupled" and
- "weakly coupled" rules. Strongly coupled in this sense means that one rule
- "firing" will clearly result in another rule firing etc.; in other words
- there is a clear (probably obvious) chain of logic. If your rules are all
+ <para>Terms like <emphasis>tight coupling</emphasis> and <emphasis>loose
+ coupling</emphasis> in systems design are generally asserted by people to mean that <emphasis>loose</emphasis> or
+ <emphasis>weak</emphasis> coupling is preferable in design terms, due to the added
+ flexibility it affords. Similarly, there can be <emphasis>strongly coupled</emphasis> and
+ <emphasis>weakly coupled</emphasis> rules. Strongly coupled in this sense means that one rule
+ <emphasis>firing</emphasis> will clearly result in another rule firing; in other words
+ there is a clear chain of logic. If the rules are all
strongly coupled, the chances are that the rules will have future
inflexibility, and more significantly, that perhaps a rule engine is
overkill (as the logic is a clear chain of rules - and can be hard coded.
[A Decision Tree may be in order]). This is not to say that strong or weak
coupling is inherently bad, but it is a point to keep in mind when
- considering a rule engine and in how you capture the rules. "Loosely"
+ considering a rule engine and in how the rules are captured. <emphasis>Loosely</emphasis>
coupled rules should result in a system that allows rules to be changed,
removed and added without requiring changes to other rules that are
unrelated.</para>
Modified: labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Comments.xml
===================================================================
--- labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Comments.xml 2008-03-31 04:11:22 UTC (rev 19331)
+++ labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Comments.xml 2008-03-31 05:59:54 UTC (rev 19332)
@@ -22,11 +22,11 @@
</mediaobject>
</figure>
- <para>To create single line comments, you can use either '#' or '//'. The
+ <para>To create single line comments, use either '#' or '//'. The
parser will ignore anything in the line after the comment symbol.
Example:</para>
- <programlisting>rule "Testing Comments"
+<screen>rule "Testing Comments"
when
# this is a single line comment
// this is also a single line comment
@@ -35,7 +35,7 @@
// this is a comment inside a semantic code block
# this is another comment in a semantic code block
end
-</programlisting>
+</screen>
</section>
<section>
@@ -55,7 +55,7 @@
<para>Multi-line comments are used to comment blocks of text, both in and
outside semantic code blocks. Example:</para>
- <programlisting>rule "Test Multi-line Comments"
+<screen>rule "Test Multi-line Comments"
when
/* this is a multi-line comment
in the left hand side of a rule */
@@ -63,6 +63,7 @@
then
/* and this is a multi-line comment
in the right hand side of a rule */
-end </programlisting>
+end
+</screen>
</section>
</section>
Modified: labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Function.xml
===================================================================
--- labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Function.xml 2008-03-31 04:11:22 UTC (rev 19331)
+++ labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Function.xml 2008-03-31 05:59:54 UTC (rev 19332)
@@ -14,43 +14,43 @@
</mediaobject>
</figure>
- <para>Functions are a way to put semantic code in your rule source file, as
- opposed to in normal Java classes. They can't do anything more then what you
- can do with helper classes (in fact, the compiler generates the helper class
- for you behind the scenes). The main advantage of using functions in a rule
- is that you can keep the logic all in one place, and you can change the
- functions as needed (this can be a good and bad thing). Functions are most
- useful for invoking actions on the consequence ("then") part of a rule,
+ <para>Functions are a way to put semantic code in the rule source file, as
+ opposed to in normal Java classes. They can't do anything more then what can be done with helper classes (in fact, the compiler generates the helper class
+ behind the scenes). The main advantage of using functions in a rule
+ is that the logic can be kept all in one place, and the functions can be changed as necessary (this can be a good and bad thing). Functions are most
+ useful for invoking actions on the consequence (<emphasis>then</emphasis>) part of a rule,
especially if that particular action is used over and over (perhaps with
- only differing parameters for each rule - for example the contents of an
+ only differing parameters for each rule; for example the contents of an
email message).</para>
<para>A typical function declaration looks like:</para>
- <programlisting>function String hello(String name) {
+<screen>function String hello(String name) {
return "Hello "+name+"!";
}
-</programlisting>
+</screen>
- <para>Note that the "function" keyword is used, even though its not really
+<note>
+ <para>The <emphasis>function</emphasis> keyword is used, even though it is not really
part of Java. Parameters to the function are just like a normal method (and
you don't have to have parameters if they are not needed). Return type is
just like a normal method.</para>
+</note>
<para>An alternative to the use of a function, could be to use a static
method in a helper class: Foo.hello(). Drools 4.0 supports the use of
- function imports, so all you would need to do is:</para>
+ function imports, so all that is needed is to do:</para>
- <programlisting>import function my.package.Foo.hello</programlisting>
+<screen>import function my.package.Foo.hello</screen>
<para>In both cases above, to use the function, just call it by its name in
the consequence or inside a semantic code block. Example:</para>
- <programlisting>rule "using a static function"
+<screen>rule "using a static function"
when
eval( true )
then
System.out.println( hello( "Bob" ) );
end
-</programlisting>
+</screen>
</section>
Modified: labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Overview.xml
===================================================================
--- labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Overview.xml 2008-03-31 04:11:22 UTC (rev 19331)
+++ labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Overview.xml 2008-03-31 05:59:54 UTC (rev 19332)
@@ -4,27 +4,25 @@
<section>
<title>Overview</title>
- <para>Drools 4.0 has a "native" rule language that is non XML textual
+ <para>Drools 4.0 has a <emphasis>native</emphasis> rule language that is non XML textual
format. This format is very light in terms of punctuation, and supports
- natural and domain specific languages via "expanders" that allow the
- language to morph to your problem domain. This chapter is mostly concerted
- with the native rule format. The Diagrams used are known as "rail road"
- diagrams, and are basically flow charts for the language terms. For the
- technically very keen, you can also refer to "DRL.g" which is the Antlr3
- grammar for the rule language. If you use the Rule Workbench, a lot of the
- rule structure is done for you with content assistance, for example, type
- "ru" and press ctrl+space, and it will build the rule structure for
- you.</para>
+ natural and domain specific languages via <emphasis>expanders</emphasis> that allow the
+ language to morph to the problem domain. This chapter is mostly concerted
+ with the native rule format. The Diagrams used are known as <emphasis>rail road</emphasis>
+ diagrams, and are flow charts for the language terms. For the
+ technically keen, <filename>DRL.g</filename> can also be refered to, which is the Antlr3
+ grammar for the rule language. When using the Rule Workbench, a lot of the
+ rule structure is done automatically with content assistance, for example, type
+ <command>ru</command> and press control (ctrl) and space, and it will build the rule structure.</para>
<section>
<title>A rule file</title>
<para>A rule file is typically a file with a .drl extension. In a drl file
- you can have multiple rules, queries and functions, as well as some
+ there can be multiple rules, queries and functions, as well as some
resource declarations like imports, globals and attributes that are
- assigned and used by your rules and queries. 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
+ assigned and used by the rules and queries. However, the rules can also be spread accross 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.</para>
@@ -49,39 +47,40 @@
<para>The order in which the elements are declared is not important,
except for the package name that, if declared, must be the first element
- in the rules file. All elements are optional, so you will use only those
- you need. We will discuss each of them in the following sections.</para>
+ in the rules file and all elements are optional. Each will be discussed in the following sections.</para>
</section>
<section>
<title>What makes a rule</title>
- <para>For the inpatients, just as an early view, a rule has the following
- rough structure:<programlisting><emphasis role="bold">rule</emphasis> <replaceable>"name"</replaceable>
+ <para>A rule has the following
+ approximate structure:<programlisting><emphasis role="bold">rule</emphasis> <replaceable>"name"</replaceable>
<replaceable>attributes</replaceable>
<emphasis role="bold">when</emphasis>
<replaceable>LHS</replaceable>
<emphasis role="bold">then</emphasis>
<replaceable>RHS</replaceable>
<emphasis role="bold">end</emphasis>
-</programlisting>Its really that simple. Mostly punctuation is not needed,
+</programlisting>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
dialect specific semantic code to be executed.</para>
- <para>It is important to note that white space is not important, EXCEPT in
- these case of domain specific languages, in which case each line is
+<note>
+ <para>White space is not important, <emphasis>EXCEPT</emphasis> in
+ the case of domain specific languages, where each line is
processed before the following line (and spaces may be significant to the
domain language).</para>
+</note>
</section>
<section>
<title>Reserved words</title>
<para>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
+ It is wise to avoid collisions with these words when naming the domain
objects, properties, methods, functions and other elements that are used
in the rule text. The parser is a bit smart and sometimes knows when a
keyword is not being used as a keyword, but avoiding the use of them might
@@ -160,9 +159,9 @@
</listitem>
</itemizedlist>
- <para>The following list are keywords that you should try and avoid in the
+ <para>The following list are keywords that should try to be avoided in the
rule contents if possible, but the parser usually will work fine, even if
- you use them for something else.</para>
+ they are used for something else.</para>
<itemizedlist>
<listitem>
@@ -270,7 +269,7 @@
</listitem>
</itemizedlist>
- <para>Of course, you can have words as part of a method name in camel
- case, like notSomething() - there are no issues with that scenario.</para>
+ <para>Words listed above can be used as part of a method name in camel
+ case, for instance; notSomething().</para>
</section>
</section>
Modified: labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Package.xml
===================================================================
--- labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Package.xml 2008-03-31 04:11:22 UTC (rev 19331)
+++ labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Package.xml 2008-03-31 05:59:54 UTC (rev 19332)
@@ -6,7 +6,7 @@
<para>A package is a collection of rules and other related constructs, such
as imports and globals. The package members are typically related to each
- other - perhaps HR rules, for instance. A package represents a namespace,
+ other, HR rules for instance. A package represents a namespace,
which ideally is kept unique for a given grouping of rules. The package name
itself is the namespace, and is not related to files or folders in any
way.</para>
@@ -15,17 +15,21 @@
one top level package configuration that all the rules are kept under (when
the rules are assembled). Although, it is not possible to merge into the
same package resources declared under different names. A single Rulebase,
- can though, contain multiple packages built on it. A common structure, is to
+ can contain multiple packages built on it. A common structure is to
have all the rules for a package in the same file as the package declaration
(so that is it entirely self contained).</para>
<para>The following rail road diagram shows all the components that may make
- up a package. Note that a package MUST have a namespace and be declared
- using standard Java conventions for package names; i.e. no spaces, unlike
- rule names which allow spaces. In terms of the order of elements, they can
- appear in any order in the rule file, with the exception of the "package"
+ up a package.</para>
+<note>
+ <para>
+ A package <emphasis>MUST</emphasis> have a namespace and be declared
+ using standard Java conventions for package names; for instance no spaces (unlike
+ rule names which allow spaces). In terms of the order of elements, they can
+ appear in any order in the rule file, with the exception of the <emphasis>package</emphasis>
and "expander" statements being at the top of the file, before any rules
appear. In all cases, the semi colons are optional.</para>
+</note>
<figure>
<title>package</title>
@@ -52,9 +56,7 @@
</mediaobject>
</figure>
- <para>Import statements work like import statements in Java. You need to
- specify the fully qualified paths and type names for any objects you want
- to use in the rules. Drools automatically imports classes from the same
+ <para>Import statements work like import statements in Java. The fully qualified paths need to be specified and type names for any objects need for use in the rules. Drools automatically imports classes from the same
named Java package and from the java.lang package.</para>
</section>
@@ -74,12 +76,16 @@
<para>The expander statement (optional) is used to specify domain specific
language (DSL) configurations (which are normally stored in a separate
- file). This provides clues to the parser as how to understand what you are
- raving on about in your rules. It is important to note that in Drools 4.0
+ file). This provides clues to the parser as how to understand the rules being parsed to it.</para>
+
+<important>
+<para>
+ In Drools 4.0
(that is different from Drools 3.x) the expander declaration is mandatory
for the tools to provide you context assist and avoiding error reporting,
but the API allows the program to apply DSL templates, even if the
expanders are not declared in the source file.</para>
+</important>
</section>
<section>
@@ -105,21 +111,20 @@
never be reasoned over, and only use them in rules LHS if the global has a
constant immutable value. The engine is not notified and does not track
globals value changes. Incorrect use of globals in constraints may yield
- surprising results - surprising in a bad way, like when a doctor says
- "thats interesting" to a chest XRay of yours.</para>
+ surprising (bad) results.</para>
<para>If multiple packages declare globals with the same identifier they
must be of the same type and all of them will reference the same global
value.</para>
- <para>In order to use globals you must:</para>
+ <para>In order to use globals these must be done:</para>
<orderedlist>
<listitem>
<para>Declare your global variable in your rules file and use it in
rules. Example:</para>
- <programlisting>global java.util.List myGlobalList;
+<screen>global java.util.List myGlobalList;
rule "Using a global"
when
@@ -127,42 +132,43 @@
then
myGlobalList.add( "Hello World" );
end
-</programlisting>
+</screen>
</listitem>
<listitem>
- <para>Set the global value on your working memory. It is a best
+ <para>Set the global value on your working memory. It is best
practice to set all global values before asserting any fact to the
working memory. Example:</para>
- <programlisting>List list = new ArrayList();
+<screen>List list = new ArrayList();
WorkingMemory wm = rulebase.newStatefulSession();
wm.setGlobal( "myGlobalList", list );
-</programlisting>
+</screen>
</listitem>
</orderedlist>
- <para>Note that these are just named instances of objects that you pass in
- from your application to the working memory. This means you can pass in
- any object you want: you could pass in a service locator, or perhaps a
- service itself. With the new 'from' element it is now common to pass a
- Hibernate session as a global, to allow 'from' to pull data from a named
+<note>
+ <para>These are just named instances of objects that are passed in
+ from the application to the working memory. This means any object can be passed in: a service locator could be passed, or perhaps a
+ service itself. With the new <emphasis>from</emphasis> element it is now common to pass a
+ Hibernate session as a global, to allow <emphasis>from</emphasis> to pull data from a named
Hibernate query.</para>
+</note>
- <para>One example may be an instance of a Email service. In your
- integration code that is calling the rule engine, you get your
- emailService object, and then set it in the working memory. In the DRL,
- you declare that you have a global of type EmailService, and give it a
- name "email". Then in your rule consequences, you can use things like
- email.sendSMS(number, message).</para>
+ <para>One example may be an instance of an Email service. In the
+ integration code that is calling the rule engine,
+ emailService object is retrieved, and then set it in the working memory. In the DRL,
+ a global of type EmailService is declared, and given a
+ name <emphasis>email</emphasis>. Then in the rule consequences,
+ email.sendSMS(number, message) can be used.</para>
<para>Globals are not designed to share data between rules and they should
never be used for that purpose. Rules always reason and react to the
- working memory state, so if you want to "share" data between rules, assert
+ working memory state, so if data has to be shared between rules, assert
the data to the working memory.</para>
<para>It is strongly discouraged to set (or change) a global value from
- inside your rules. We recommend to you always set the value from your
+ inside the rules. It is recommended to always set the value from the
application using the working memory interface.</para>
</section>
</section>
Modified: labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Rule.xml
===================================================================
--- labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Rule.xml 2008-03-31 04:11:22 UTC (rev 19331)
+++ labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-Rule.xml 2008-03-31 05:59:54 UTC (rev 19332)
@@ -14,18 +14,18 @@
</mediaobject>
</figure>
- <para>A rule specifies that "when" a particular set of conditions occur,
+ <para>A rule specifies that <emphasis>when</emphasis> a particular set of conditions occur,
specified in the Left Hand Side (LHS), then do this, which is specified as a
list of actions in the Right Hand Side (RHS). A common question from users
- is "why use when instead of if". "when" was chosen over "if" because "if" is
+ is "why use when instead of if?". <emphasis>when</emphasis> was chosen over <emphasis>if</emphasis> because <emphasis>if</emphasis> is
normally part of a procedural execution flow, where at a specific point in
- time it checks the condition. Where as "when" indicates it's not tied to a
+ time it checks the condition. Whereas <emphasis>when</emphasis> indicates it is not tied to a
specific evaluation sequence or point in time, at any time during the life
- time of the engine "when" this occurs, do that. Rule</para>
+ time of the engine <emphasis>when</emphasis> this occurs, do that.</para>
<para>A rule must have a name, and be a unique name for the rule package. If
- you define a rule twice in the same DRL it produce an error while loading.
- If you add a DRL that has includes a rule name already in the package, it
+ a rule is defined twice in the same DRL it produces an error while loading.
+ If a DRL is added that includes a rule name already in the package, it
will replace the previous rule. If a rule name is to have spaces, then it
will need to be in double quotes (its best to always use double
quotes).</para>
@@ -33,27 +33,29 @@
<para>Attributes are optional, and are described below (they are best kept
as one per line).</para>
- <para>The LHS of the rule follows the "when" keyword (ideally on a new
- line), similarly the RHS follows the "then" keyword (ideally on a newline).
- The rule is terminated by the keyword "end". Rules cannot be nested of
+ <para>The LHS of the rule follows the <emphasis>when</emphasis> keyword (ideally on a new
+ line), similarly the RHS follows the <emphasis>then</emphasis> keyword (ideally on a newline).
+ The rule is terminated by the keyword <emphasis>end</emphasis>. Rules cannot be nested of
course.</para>
<example>
<title>Rule Syntax Overview Example</title>
- <programlisting>rule "<name>"
+<screen>rule "<name>"
<attribute>*
when
<conditional element>*
then
<action>*
-end</programlisting>
+end
+</screen>
</example>
<example>
<title>A rule example</title>
- <programlisting>rule "Approve if not rejected"
+<screen>
+rule "Approve if not rejected"
salience -100
agenda-group "approval"
when
@@ -64,7 +66,8 @@
then
log("APPROVED: due to no objections.");
p.setApproved(true);
-end</programlisting>
+end
+</screen>
</example>
<section>
@@ -72,8 +75,7 @@
<para>Rule attributes provide a declarative way to influence the behavior
of the rule, some are quite simple, while others are part of complex sub
- systems; such as ruleflow. To get the most from Drools you should make
- sure you have a proper understanding of each attribute.</para>
+ systems; such as ruleflow. To get the most from Drools it is best to have a proper understanding of each arrtribute.</para>
<figure>
<title>rule attributes</title>
@@ -107,7 +109,9 @@
<para>type : Boolean</para>
- <para>when a ruleflow-group becomes active or an agenda-group receives the focus any rules that ahve lock-on-active set to try cannot place activations onto the agenda, the rules are matched and the resulting activations discarded. This is a stronger version of no-loop. It's ideally for calculation rules where you have a number of rules that will modify a fact and you don't want any rule re-matching and firing. In summary fire these currently active rules and only these rules, no matter how the data changes, do not allow any more activations for the rules with the attribute set to true. When the ruleflow-group is no longer active or agenda-group loses the focus those rules with lock-on-active set to true can once again add activations onto the agenda.</para>
+ <para>When a ruleflow-group becomes active or an agenda-group receives the focus any rules that have <property>lock-on-active</property> set to try cannot place activations onto the agenda, the rules are matched and the resulting activations discarded. This is a stronger version of no-loop. It is ideally for calculation rules where there are a number of rules that will modify a fact and a rule is not be be re-matched and fired.</para>
+
+ <para>In summary, firing these currently active rules and only these rules, no matter how the data changes, do not allow any more activations for the rules with the attribute is set to true. When the ruleflow-group is no longer active or <property>agenda-group</property> loses the focus those rules with <property>lock-on-active</property> set to true can once again add activations onto the agenda.</para>
</listitem>
</varlistentry>
@@ -119,7 +123,7 @@
<para>type : integer</para>
- <para>Each rule has a salience attribute that can be assigned an Integer number, defaults to zero, the Integer and can be negative or positive. Salience is a form of priority where rules with higher salience values are given higher priority when ordered in the Activation queue.</para>
+ <para>Each rule has a salience attribute that can be assigned an Integer number (default is zero), and can be negative or positive. Salience is a form of priority where rules with higher salience values are given higher priority when ordered in the Activation queue.</para>
</listitem>
</varlistentry>
@@ -158,7 +162,9 @@
<para>Rules that belong to the same named activation-group will only fire exclusively. In other words, the first rule in an activation-group to fire will cancel the other rules activations (stop them from firing). The Activation group attribute is any string, as long as the string is identical for all the rules you need to be in the one group.</para>
- <para>NOTE: this used to be called Xor group, but technically its not quite an Xor, but you may hear people mention Xor group, just swap that term in your mind with activation-group.</para>
+ <note>
+ <para>This used to be called <emphasis>Xor</emphasis> group, but technically its not quite an Xor, but you may hear people mention Xor group, just swap that term in your mind with activation-group.</para>
+ </note>
</listitem>
</varlistentry>
@@ -172,7 +178,7 @@
<para>possible values: "java" or "mvel"</para>
- <para>The dialect species the language to be used for any code
+ <para>The dialect specifies the language to be used for any code
expressions in the LHS or the RHS code block. Currently two dialects are available, Java and MVEL. While the dialect can be specified at the package level, this attribute allows the package definition to be overridden.</para>
</listitem>
</varlistentry>
@@ -186,7 +192,7 @@
<para>type : String, which contains a Date/Time definition</para>
- <para>A rule can only activate if the current date and time is after date-effective attribute.</para>
+ <para>A rule can only activate if the current date and time is after the date-effective attribute.</para>
</listitem>
</varlistentry>
@@ -198,7 +204,7 @@
<para>type : String, which contains a Date/Time definition</para>
- <para>A rule cannot activate if the current date and time is after date-expires attribute.</para>
+ <para>A rule cannot activate if the current date and time is after the date-expires attribute.</para>
</listitem>
</varlistentry>
@@ -216,13 +222,12 @@
</variablelist>
<example>
- <title>Some attribute examples</title>
+ <title>An attribute example</title>
- <programlisting>rule "my rule"
+rule "my rule"
salience 42
agenda-group "number 1"
when ...
-</programlisting>
</example>
</section>
@@ -232,7 +237,7 @@
<para>The Left Hand Side (LHS) is a common name for the conditional part
of the rule. It consists of zero or more Conditional Elements. If the LHS
is left empty it is re-written as eval(true), which means the rule is
- always true, and will be activated with a new Working Memory session is
+ always true, and will be activated when a new Working Memory session is
created.</para>
<figure>
@@ -248,20 +253,24 @@
<example>
<title>Rule Syntax Overview Example</title>
- <programlisting>rule "no CEs"
+<screen>
+rule "no CEs"
when
then
<action>*
-end</programlisting>
+end
+</screen>
<para>Is internally re-written as:</para>
- <programlisting>rule "no CEs"
+<screen>
+rule "no CEs"
when
eval( true )
then
<action>*
-end</programlisting>
+end
+</screen>
</example>
<para>Conditional elements work on one or more Patterns (which are
More information about the jboss-svn-commits
mailing list