[rules-users] RE: questions on guvnor and drools 5.0

Garner, Shawn Garner.Shawn at principal.com
Thu Jun 4 13:41:54 EDT 2009


We have lists of objects and I was talking about how you do it with the test scenario in Guvnor.

The fact is in working memory but I need to be able to create the object so it has a list of objects.

Because the rule matches if it is in working memory and party of another object's list.

So if I have a School and Children for example

Then I write a rule that says if School and Child where child is a member of the School

[when]
	$child : Child(readyForRegistration == true)
	$school : School($child memberof children)
[then]
	$school.registerChild($child);
[end]

So in Guvnor I need to create a test scenario where School has a list of Children objects.  But Guvnor only shows me a textfield so I assume it wants a value like "Bob" or 1.  

I don't see the option or an example how to create a Child fact with a name of Bob and readyForRegistration = true.  

Then another child with name of Nancy which readyForRegistration = false.

Then I want to put them in both into a collection and create a new School object using the collection of Bob and Nancy.


I can do this type of thing easily with a JUnit test creating and inserting facts into working memory.  It would be nice if business users could write test scenarios just as easy with Guvnor.

If you haven't checked out that part of Guvnor it might help if you take a peek.

SG

-----Original Message-----
From: rules-users-bounces at lists.jboss.org [mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Wolfgang Laun
Sent: Thursday, June 04, 2009 11:59 AM
To: Rules Users List
Subject: Re: [rules-users] RE: questions on guvnor and drools 5.0

On 6/4/09, Garner, Shawn <Garner.Shawn at principal.com> wrote:
> 2) How do you use the test scenarios with complex object structures?
>        -eg Create a fact in working memory that has another Object in it which in turn has a list of Objects in it.
>        -Seems like any Fact in working memory is assumed to only have only primitive values like Strings or numbers.
>        -We would like a more depth of objects where objects have a deep relationship to other objects at least 2-4 levels deep.

Any object that is inserted as a fact may contain references to other
objects, which, in turn, may contain references, and so on.

The main thing to consider with complex object structures is, which of
the objects should be inserted as facts. The distinction should be
made according to whether an object's properties participate in rule
patterns and whether this object will change during the (stateful)
session. If so, make it a fact.

Referring to object properties via one or more levels of dereferencing
when using them in patterns won't be possible except in inline evals
or eval patterns.

Notice that LHS patterns may be written so that additional levels of
objects are included in the reasoning, letting you access their
non-reference fields in field constraints, e.g.:

rule x
when
   $p : Person( $name : name, $f : father )
   Person( this == $f, name == "Joe" )
then
   // $name is a child of Joe
end

-W
_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to Connect at principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.





More information about the rules-users mailing list