[Jboss-svn-commits] JBL Code SVN: r4205 - labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language

[<jbo...@li...>]

Author: mic...@jb...
Date: 2006-05-12 05:30:03 -0400 (Fri, 12 May 2006)
New Revision: 4205

Modified:
   labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-DSL.xml
Log:
new deployment section

Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-DSL.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-DSL.xml	2006-05-12 09:29:47 UTC (rev 4204)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-DSL.xml	2006-05-12 09:30:03 UTC (rev 4205)
@@ -24,10 +24,16 @@
 
     <para>DSLs have no impact on the rules at runtime, they are just a
     parse/compile time feature.</para>
+
+    <para>Note that Drools 3 DSLs are quite different from Drools 2 XML based
+    DSLs. It is still possible to do Drools 2 style XML languages - if you
+    require this, then take a look at the Drools 3 XML rule language, and
+    consider using XSLT to map from your XML language to the Drools 3 XML
+    language.</para>
   </section>
 
   <section>
-    <title>Creating and editing a DSL</title>
+    <title>Editing and managing a DSL</title>
 
     <para>A DSL's configuration like most things is stored in plain text. If
     you use the IDE, you get a nice graphical editor (with some validation),
@@ -89,8 +95,8 @@
 
     <para>The "{" and "}" characters should only be used on the left hand side
     of the mapping (the expression) to mark tokens. On the right hand side you
-    can use "{" and "}" on their own if needed (such as if (foo) {
-    doSomething(); } ) as well as with the token names as shown above.</para>
+    can use "{" and "}" on their own if needed - such as <programlisting>if (foo) {
+    doSomething(); }</programlisting>  as well as with the token names as shown above.</para>
 
     <para>Don't forget that if you are capturing strings from users, you will
     also need the quotes on the right hand side of the mapping, just like a
@@ -198,4 +204,52 @@
     Expander and ExpanderResolver interfaces, it is possible to plug in your
     own advanced expanders if required.</para>
   </section>
+
+  <section>
+	<title>Creating a DSL from scratch</title>
+	<para>
+		DSLs can be aid with capturing rules if the rules are well known, just not in any technically usable format (ie. sitting around in people brains).
+		Until we are able to have those little sockets in our necks like in the Matrix, our means of getting stuff into computers is still the old fashioned way.
+	</para>
+	<para>
+		Rules engines require a object or data model to operate on - in many cases you may know this up front. In othercases the model will be discovered with the rules.
+		In any case, rules generally work better with simpler flatter object models. In some cases, this may mean having a rule object model which is a subset of the main applications model (perhaps mapped from it). Object models can often have complex relationships and hierachies in them - for rules you will want to simplify and flatten the model where possible, and let the rule engine infer relationships (as it provides future flexibility).
+		As stated previously, DSLs can have an advantage of providing some insulation between the object model and the rule language.
+	</para>
+	<para>
+		Coming up with a DSL is a collaborative approach for both technical and domain experts. Historically there was a role called "knowledge engineer" which is someone skilled in both the rule technology, and in capturing rules. Overa short period of time, your DSL should stabilise, which means that changes to rules are done entirely using the DSL. 
+		A suggested approach if you are starting from scratch is the following workflow:
+
+          <itemizedlist>
+            <listitem>
+              <para>Capture rules as loose "if then" statements - this is really to get an idea of size and complexity (possibly in a text document).</para>
+            </listitem>
+
+            <listitem>
+              <para>Look for recurring statements in the rules captured. Also look for the rule objects/fields (and match them up with what may already be known of the object model).</para>
+            </listitem>
+
+            <listitem>
+              <para>Create a new DSL, and start adding statements from the above steps. Provide the "holes" for data to be edited (as many statements will be similar, with only some data changing).</para>
+            </listitem>
+
+            <listitem>
+              <para>Use the above DSL, and try to write the rules just like that appear in the "if then" statements from the first and second steps. Iterate this process until patterns appear and things stabilise. At this stage, you are not so worried about the rule language underneath, just the DSL.</para>
+            </listitem>
+
+            <listitem>
+              <para>At this stage you will need to look at the Objects, and the Fields that are needed for the rules, reconcile this with the datamodel so far.</para>
+            </listitem>
+
+            <listitem>
+              <para>Map the DSL statements to the rule language, based on the object model. Then repeat the process. Obviously this is best done in small steps, to make sure that things are on the right track.</para>
+            </listitem>
+          </itemizedlist>
+	</para>
+
+	<para>
+		A challanging concept to express in DSLs is bound variables. A tip for this is to have a DSL expressions that just bind a given variable name to an Object Type (with no conditions - you can add conditions to that bound object type in subsequent statements). You can then use that name elsewhere in the DSL (including in the action part of the rule). 
+	</para>
+
+  </section>
 </section>
\ No newline at end of file