   Hi Stephen,

   I am kind of lost by the line numbers and changes you mentioned. Maybe you can submit a code patch? This way we can see exactly what is being changed, discuss the impact if it is the case, and apply it to the codebase.

> Was this the fundamental problem with templates

   There are a few issues on how templates were implemented. The main one, and probably the main reason we did not extended the functionality to support any underlying fact format, is the syntax support on semantic code blocks. I.e. dialect support, specially on consequences. For instance, imagine that you want to read the attribute "age" from the "Person" fact in the consequence of a rule. Ideally, you want to do something like bellow, does not matter what the underlying format of Person is. After all, Person is a fact:

rule ...
when
   $p : Person(...)...
then
   int age = $p.age;
end

   Above will work for java and MVEL, if the format is POJO. Now with templates, you must do something like:

int age = ((Integer) $p.getAttribute( "age" )).intValue();

   Now, imagine that your fact is an XML element, or a database record? In the end, your rules will be tied to the underlying format and format pluggability will lose much of its value.

   So, the big issue, IMO, is that we must implement format transparency on the semantic code blocks. Implementing format support for non-semantic blocks is pretty straight-forward and the proof-of-concept is that we do it already (although not extensively tested) with templates.

   But don't give up. :) It is possible to do it, we just lack manpower to do all we want, and if it is something you will use, we can work together using an incremental approach. First we make sure everything is correctly wired and working for multiple underlying formats, and then we deal with the dialect support.

   Regarding merge of packages, it is quite simple. You can merge packages either at compilation time, by using the package builder and adding your prereq artifacts first, or directly at rulebase building time by adding multiple packages. Also, Mark did an extensive work on binary references rewiring a couple of weeks ago to ensure we have a clean binary in-memory structure, without classloader leaks.

   Cheers,
       Edson

2008/8/27 Stephen Kestle <stephen.kestle@orionhealth.com>

This is a follow up to my reply to http://article.gmane.org/gmane.comp.java.drools.user/12319 :)

What I would like are some changes to PackageBuilder (line numbers at r21562):

Remove/change lines 632-641 as they call pkgRegistry.getPackage().getFactTemplate, where fact templates are compiled into the package after 393, which is after 381->551->570->634. Ok, so perhaps it is possible, if you define your templates in another package...

Change TypeDeclaration.Format to a class, instead of an enum. We want our own type. At line 632, insert something like the following:

final String format = ObjectUtils.defaultIfNull(typeDescr.getMetaAttribute( TypeDeclaration.ATTR_FORMAT).toLowerCase(), "pojo"); //ATTR_FORMAT="format"
TypeFactory factory = packageDesc.getTypeFactory(format); //where packages have a typeFactory declaration of a class that implements TypeFactory (which has a getFormat() for registration purposes)
TypeDeclaration type = factory.create(typeDescr);

lines 643-674 get moved into PojoTypeFactory.create();

Something needs to be done to TypeDeclaration to allow non-class based implementations. After all, it makes no sense (to me) to call a method that then just refers to a map of name-values.

However, drools uses java object types/classes heavily for rules optimisations - and type references. Is this unavoidable? Was this the fundamental problem with templates - that one could not be composed inside another because the type could not be referenced (by a class)?

Also, I'm looking for a way to do partial compilation... I want to create a description with fundamental declarations and imports for our product to simplify the text ones, but I can't figure out how to merge - is it just a case of declaring my core package, and then "adding" the same one from the file?

Cheers

Stephen

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com