[rules-users] Writing rules against derived facts.

[Mark Proctor]

Drools does not currently support dynamic properties on objects, only 
concrete java classes. The fact template stuff is experimental and thus 
not documented and not gauranteed to work :)

Partly this is because we are not sure how to effectively expose Fact 
Templates to the java dialect, I think it would be combersome for people 
to have to do
fact.getValue( "name" );
fact.setValue( "name", "drools" );

One thing we are thinking of doing is dumping FactTemplates and instead 
doing runtime bean generation based on definitions in the drl file, 
although you still have some dynamic issues there. If you add/remove 
fields only new instances would get the changes.

So there is a lot of research here to get it right, and I really want to 
tie it in with some sort of ontology constraint model.

Mark
Faron Dutton wrote:
> Hi,
>
> I am having trouble understanding why the following does not work in 4.0.4.
>
> rule "A"
>     when
>         foo : Foo( bar == true )
>     then
>         insertLogical( new DerivedFact( "relationName", foo, Boolean.TRUE ) );
> end
>
> rule "B"
>     when
>         tuple : DerivedFact( name == "relationName" )
>     then
>         // < do something with tuple >
> end
>
> Rule A fires and adds a new DerivedFact to the working memory as a
> shadow fact. Rule B then fires but name is always null in the shadow
> object even though name is set in the delegate.
>
> My main goal is to reason about an existing model that I cannot change
> and without adding a lot of new elements as some sort of shadow model.
> I wanted to add additional properties to the model so I tried using
> Java dynamic proxies to add a new interface, which did not work as I
> got ClassCastExceptions during consequence execution. I then tried
> using fact templates but I get compilation errors when the compiler
> cannot find the DerivedFact class. I finally just added DerivedFact as
> a normal class, which is where I am now. I would really like to get
> back to the original goal of adding properties to the model so that
> the rules are easier to understand. For example, the above code would
> then be:
>
> rule "A"
>     when
>         foo : Foo( bar == true )
>     then
>         foo.relationName = true; // or foo.setRelationName(true);
> end
>
> rule "B"
>     when
>         foo : Foo( relationName == true )
>     then
>         // < do something with foo >
> end
>
> Any insight would be greatly appreciated.
> Faron.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>