[rules-dev] TypeDeclaration plugin heirarchy

[Edson Tirelli]

   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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20080827/19bc0d4d/attachment.html