   Stephen,

   Really glad to see you picking up this stuff.

   Let me clarify something: "templates" were an experimental feature in Drools 4.0, and so far, will continue to be experimental in Drools 5.0 as we lack the manpower to move it ahead ourselves. If you are willing to move this ahead, we can provide all assistance/guidance you may need.

   Having said that, lets split the template construct into concept and syntax. The syntax is being completely removed in Drools 5 and replaced by the TypeDeclaration syntax. The type declaration concept is more abstract than template (or should I say a super set?). Type declaration in drools 5 has 2 purposes: 1st it is a way to assign metadata to types, 2nd it is a way to declare/generate underlying structures for facts.

   So talking about the first usage, as it is today, you can have an existing fact type (e.g. a class named StockTick) and assign metadata for it. For instance, saying it should be given "event semantics" in the system:

declare StockTick
   @role( event )
end

   Talking about the second usage, the idea is that you can declare types that may have any underlying implementation would best fit you. So far, the underlying implementation that we have working and tested is POJO generation.

declare Address
    line1 : String
    line2 : String
end

declare Person
    name : String
    age : int
    address : Address
end

   Now, it is planned, though not implemented/wired/tested yet, that when you declare a type, you may inform the engine what is its underlying format and the engine will know how to handle it:

declare Address
    @format( template )
    line1 : String
    line2 : String
end

   Idea is that you could have any arbitrary underlying format for facts, like XML, JMS Messages, Database Records, CSV records, etc.

   Anyway, that is the vision. If you look at the PackageBuilder.java, line 602, processTypeDeclaration() method, that is where the compilation/wiring process starts. We probably need to extract that method and create a separate API for it. The code there is not tested except for POJOs. If you look at the line 631, it has an "if" from the first idea we had, where you would use "template" construct to create a template and then a "declare" construct to assign metadata to it. We dropped this idea, since a unified approach is better, but that code is still there:

            // is it a POJO or a template?
            String templateName = typeDescr.getMetaAttribute( TypeDeclaration.ATTR_TEMPLATE );

    Also, just for the sake of completeness, the final vision is to allow both initialization expressions and attribute validation in the type declaration. For instance:

declare Person
    name : String( length < 30 ) @key
    age : int( value >= 0 && < 150 ) = 0
    addresses : Map<String, Address> = {"home" : null, "business" : null}
end

   There are a few more bits like automatic creation of facts, but that is subject for another time.

    There is a lot to do, but it can be easily split into an incremental approach. If you want to contribute working on this, it will be a pleasure to support you.

    Cheers,
       Edson

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

I believe I have it... "declare" is meant to be used for easy generation of java classes, so that rules can instantiate objects and use them as such. For dynamic data models, "template" is a better fit, as getField etc are geared towards map-like data structures.

I believe that I could have :

template "Address"
String line1
String line2
end

template "Person"
String name
int age
Object address
end

rule "Test"
    when
        add: Address(line1 == "address")
        person: Person(address == add)
    then
        ...

Is this correct?

Cheers

Stephen Kestle wrote:
I'm creating a type hierarchy using TypeDeclarations based on an ontological model (analagous to an xml schema for the purposes of this post).

If I declare a drl file to have the following declarations

declare Address
line1 : String
line2 : String
end

declare Person
name : String
age : int
address : Address
end

it will create Java Pojo classes for me. However, I had it all working using fact templates, except for the address item. Is it possible to insert fact implementations based on templates, while declaring TypeDeclarations in the drl? (I now go to look for how to specify the format = TEMPLATE for the drl)

I say this because I'm looking up values using id strings - e.g. the exact same way that FactTemplate based Facts does accessing. I don't want to have to convert all my String ids to reflectively call the set methods on the created Pojo.

Hopefully this is enough info for you 5.0 developers - I'm still trying to wrap my head around it all.

Cheers

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

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

--

Stephen Kestle Software Engineer
stephen.kestle@orionhealth.com
P: +64 9 638 0619
M: +64 27 453 7853
F: +64 9 638 0699
S: skestle
www.orionhealth.com

This e-mail and any attachments are intended only for the person to whom it is addressed and may contain privileged, proprietary, or other data protected from disclosure under applicable law. If you are not the addressee or the person responsible for delivering this to the addressee you are hereby notified that reading, copying or distributing this transmission is prohibited. If you have received this e-mail in error, please telephone us immediately and remove all copies of it from your system. Thank you for your co-operation.

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

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