Was this the fundamental problem with templates

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Edson Tirelli wrote: 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. Yes, I thought $person.getFieldValue("age") was a bit annoying... But the more I look into the code and interfaces around FactTemplate, the more I like it's approach and it's fit for ontological (dynamic model/schema) data models. 1. MVEL etc needs to reflect on methods to give the dialect support to POJOs 2. To make an dynamic model fit to OO, TypeDeclarations would need to be able to generate interfaces, an a proxy mechanism would be needed for the map-backed model - this just seems too retarded 3. Surely TypeDeclaration should be an interface with methods to gain method information and types etc. PojoTypeDeclaration would implement this using the reflective model as current. TemplateTypeDeclaration would use the FactTemplate to do it (if it was being continued). This way maximum pluggability is maintained. 4. Isn't this what FactTemplate does? I see the problem is that FactTemplate was an add-on, instead of a super set / *the* way of accessing fact type information. 5. Is this idea awesome? Calling TypeDeclaration.execute("getAge") does not seem any different to how it is now - how "compiled" are these rules? If they are byte-compiled, then that optimisation could be done for PojoTypeDeclaration. How correct am I on these points? Cheers Stephen

I'm starting to get my head around the classes and structure, but I'm

Edson Tirelli wrote: Hi Stephen, Nice job inspecting our code base. The complete type abstraction layer in Drools is composed by several interfaces and its corresponding implementations. * TypeDeclaration is just that: a stateless type representation for describing Facts. It is not supposed to know how to actually read fact value, attributes, etc. It is used at compilation and runtime to read metainformation about a fact and is not tied to any particular fact instance. Except that it is tied in particular to FactTemplate and classes. It should expose the required metadata completely. * To handle a Type, i.e., evaluate if a type matches a pattern and manipulate the type at compile and runtime, we have an ObjectType interface. That interface, today, has 2 implementations: ClassObjectType (for POJO) and FactTemplateObjectType (for templates). * To read the internals of a type we have the ReadAccessor and WriteAccessor interfaces. These interface implementations are lazyly bytecode generated for extremely fast access and fact manipulation at runtime. So, in your example, there would be an AgeReadAccessor to do this: TypeDeclaration.execute("getAge"). TypeDeclaration should only interact with the compiler, not the actual facts. Ok - so there's sneaky compilation going on everywhere. So reflection is not used at all (at least at runtime). Also, There is not FactTemplateWriteAccessor, so we cannot set fields, except by using Fact.setFieldValue(). If there was a write accessor (and a FactField implementation and plugging for FactTemplate) then it would be complete? I'm starting to get my head around the classes and structure, but I'm still struggling to see what's wrong with FactTemplate. It seems relatively valid. Why couldn't it be finished? Also, is there any way of actually using TypeDeclarations outside of a package script or javabean? e.g. there's no simple way of getting existing objects into a template without writing a bit of reflection... Thanks 2008/8/28 Stephen Kestle <stephen.kestle(a)orionhealth.com&gt; > > > Edson Tirelli wrote: > > 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. > > Yes, I thought $person.getFieldValue("age") was a bit annoying... > > But the more I look into the code and interfaces around FactTemplate, the > more I like it's approach and it's fit for ontological (dynamic > model/schema) data models. > > 1. MVEL etc needs to reflect on methods to give the dialect support to > POJOs > 2. To make an dynamic model fit to OO, TypeDeclarations would need to > be able to generate interfaces, an a proxy mechanism would be needed for the > map-backed model - this just seems too retarded > 3. Surely TypeDeclaration should be an interface with methods to gain > method information and types etc. PojoTypeDeclaration would implement this > using the reflective model as current. TemplateTypeDeclaration would use > the FactTemplate to do it (if it was being continued). This way maximum > pluggability is maintained. > 4. Isn't this what FactTemplate does? I see the problem is that > FactTemplate was an add-on, instead of a super set / *the* way of accessing > fact type information. > 5. Is this idea awesome? Calling TypeDeclaration.execute("getAge") > does not seem any different to how it is now - how "compiled" are these > rules? If they are byte-compiled, then that optimisation could be done for > PojoTypeDeclaration. > > How correct am I on these points? > > Cheers > > Stephen > -- Edson Tirelli JBoss Drools Core Development JBoss, a division of Red Hat @ www.jboss.com ------------------------------ _______________________________________________ rules-dev mailing listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev co-operation. _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev