[rules-users] Dynamic Fact Types

[Swindells, Thomas]

Another approach would be to use a bytecode manipulation library to generate your java beans - that is you don't actually compile them from java code but programatically declare the fields (and methods if you want them) and write it straight out as a new java class .

From: rules-users-bounces at lists.jboss.org [mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Wolfgang Laun
Sent: 10 February 2011 08:02
To: Rules Users List
Subject: Re: [rules-users] Dynamic Fact Types

(Fact Templates are over and out.)

You create a TypeDeclaration by writing a DRL declare, which results in a considerable number of objects being created and available at run time: TypeDeclaration, ClassDefinition, FactField and FieldDeclaration and several other objects, the "accessors" So, you could create a piece of DRL text containing "declare X ... end" and pass this to the builder and add the resulting package to your Knowledge Base.

And then?

You'll need some code to get objects of type X into Working Memory, which you can do using the reflection-like methods of FactType and FactField, but this code still has to know about "X" and its field names.

OK, so you have some Xs in WM. And now?

You'll have to write some rules referring to X and its fields, and how can you do that? More DRL text?

True, rule patterns can use interface names as type names, but the DRL language doesn't let you declare a type with an "implements" clause, and therefore the Engine simply wouldn't know that your X implements anything.

Finally, a poster on this list has stated just a few days ago that declared types are considerably slower than Java types. This hasn't been confirmed or explained by one of the developers (although the additional layers mentioned previously are certainly not speeding things up).

I don't know enough about your problem to suggest anything. It could be that sticking with the Object/JavaBeans model and generating and compiling Java and DRL is best. Or it could be that an entirely different ontology model is advisable (even though the Drools fact model is clearly JavaBean-ish). Or maybe you shouldn't use rules at all ;-)

-W

On 9 February 2011 23:02, jwillans2 <james.willans at ceteva.com<mailto:james.willans at ceteva.com>> wrote:

Hello,

I am looking for an approach to defining fact types
dynamically/programmatically.  Having hunted about, I can see a few ways of
achieving this.  My preferred approach to doing this would be Fact Templates
as described in the blog article here:

http://orangemile.blogspot.com/2008/07/drools-fact-template-example.html

I can see two problems with this approaches.  Firstly, it seems to be an
experimental feature and generally not supported.  Secondly, it only seems
to work with primitive fields (perhaps I'm wrong here?).  I get the
impression that the preferred option is to use Type Declarations.  In the
documentation for Type Declarations, it suggests that the rules evaluate
against an interface rather than an actual Java object and that the
interface can be implemented using different methods (POJO, reflection ..).
Is there any examples or documentation on how to do this beyond generated
Java bean class? Just to be clear, I am looking to define the fact types
programmatic in a similar manner to that described in the above blog link,
and I am eager to avoid a compilation/class loader step.

Many thanks for any help that can be offered,

James
--
View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Dynamic-Fact-Types-tp2462037p2462037.html
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org<mailto:rules-users at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users


________________________________

**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster at nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110210/f661372e/attachment.html