[jboss-svn-commits] JBL Code SVN: r5034 - labs/jbossrules/branches/3.0.x/documentation/manual/en/Chapter-Rule_Language

[jboss-svn-commits at lists.jboss.org]

Author: michael.neale at jboss.com
Date: 2006-07-12 00:56:24 -0400 (Wed, 12 Jul 2006)
New Revision: 5034

Modified:
   labs/jbossrules/branches/3.0.x/documentation/manual/en/Chapter-Rule_Language/Section-Rule.xml
Log:
updated for info on bean capitalisation

Modified: labs/jbossrules/branches/3.0.x/documentation/manual/en/Chapter-Rule_Language/Section-Rule.xml
===================================================================
--- labs/jbossrules/branches/3.0.x/documentation/manual/en/Chapter-Rule_Language/Section-Rule.xml	2006-07-12 03:08:14 UTC (rev 5033)
+++ labs/jbossrules/branches/3.0.x/documentation/manual/en/Chapter-Rule_Language/Section-Rule.xml	2006-07-12 04:56:24 UTC (rev 5034)
@@ -286,20 +286,21 @@
 
       <para>A "field" is not a field in the sense of a public or private
       member of a class. A field is an accessible method. If your model
-      objects follow the java bean pattern, then fields are accessed via
+      objects follow the java bean pattern, then fields are exposed using
       "getXXX" or "isXXX" methods (these are methods that take no arguments,
       and return something). You can access fields either by using the
-      bean-name convention (so "getType" can be accessed as "type") or by
-      specifying the whole method name (without any brackets).</para>
+      bean-name convention (so "getType" can be accessed as "type").</para>
 
-      <para>For example, refering to our Cheese class, the following are
-      equivalent: Cheese(type == ...), and Cheese(getType == ...). This means
-      that you can use model objects that aren't strictly java beans. However,
-      make sure that you are accessing methods that take no parameters, and
-      are infact "accessors" (as in, they don't change the state of the object
-      in a way that may effect the rules - remember that the rule engine
-      effectively caches the results of its matching inbetween invocations to
-      make it faster).</para>
+      <para>For example, refering to our Cheese class, the following :
+      Cheese(type == ...) uses the getType() method on the a cheese instance.
+      You can also access non getter methods, like "toString()" on the Object
+      for instance (in which case, you do Cheese(toString == ..) - you use the full name of the 
+      method with correct capitalisation, but not brackets).
+      Do please make sure that you are accessing methods that
+      take no parameters, and are in-fact "accessors" (as in, they don't change
+      the state of the object in a way that may effect the rules - remember
+      that the rule engine effectively caches the results of its matching
+      inbetween invocations to make it faster).</para>
 
       <para>Note that if primitive types are used for a field, Drools will
       autobox them to their corresponding object types (even if you are using
@@ -307,9 +308,22 @@
       inside code expressions or blocks. On the whole, it is probably best to
       use the non primitive types in the model objects you are using in your
       rules. If you use Java 5, then you get the best of both worlds (you can
-      let the compiler autobox for you - much neater).</para>
+      let the compiler autobox for you - much neater) if you use Java 5,
+      Drools will honor that if you use the JDT semantic compiler (JANINO does
+      not yet support Java 5).</para>
 
       <section>
+	<title>JavaBeans as facts</title>
+	      <para>A note on JavaBeans: The JavaBean convention is followed, but as
+     	 shown above, you can access non getter methods by using the method name.
+      	The syntax is case sensitive. In the case of getter methods like
+      	"getURI" which uses capitals, the property name is "URI" as there is
+      	more then one capital letter after the "get" - this is exactly as per
+      	the JavaBean standard (in fact, the Instrospector utility is used).
+      </para>
+      </section>
+      
+      <section>
         <title>Operators</title>
 
         <figure>
@@ -779,7 +793,7 @@
       called sub rules, for each possible logically outcome. the example above
       would result in the internal generation of two rules. These two rules
       work independently within the Working Memory, which means both can
-      match, activate and fire - there is no shortcutting. </para>
+      match, activate and fire - there is no shortcutting.</para>
 
       <para>The best way to think of the OR conditional element is as a
       shortcut for generating 2 additional rules. When you think of it that
@@ -985,4 +999,4 @@
     ! The fact that not quite *everything* in java is an object causes
     headaches like this (keep those tablets handy).</para>
   </section>
-</section>
\ No newline at end of file
+</section>