6:04 p.m.
Guys - are there going to be any changes to the compiler API now? Cause now
is the time to fix/change it if needed.
I have some suggestions if anyone is interested.
6:13 p.m.
Suggest away.
Mark
Michael Neale wrote:
Guys - are there going to be any changes to the compiler API now?
Cause now is the time to fix/change it if needed.
I have some suggestions if anyone is interested.
------------------------------------------------------------------------
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6:34 p.m.
although drools-compiler has the descr classes, it would be nice to have an
Rule Object Model like the one I showed you guys.
this way, a condition would be represented by a condition object like this
public class Condition {
/**
* Added the attribute to make it easier to compile the rule to
* java code
*/
private String objectType;
/**
* if the attribute is bound to a variable, the method
* should return the name of the variable.
*/
private String boundVariable;
/**
* the attribute of the object to match on
*/
private String attribute;
/**
* the operator for the condition, which may be ==, !=
* <, >, <=, >=, <>
*/
private String operator;
/**
* The timestamp of the last change made to the condition.
* this attribute is optional and is meant to make it
* easier to run queries on the rules by timestamp
*/
private long timestamp;
/**
* the value of the condition
*/
private String value;
/**
* the value can be either a single literal value or a list
* of values of the same type
*/
private String valueType = null;
/**
* the version of the condition. for advanced reporting, it's
* easier if the condition is tagged with a version number.
*/
private String version;
}
I'm totally bias, but it would make writing tools easier. things like rule
repo, validation, impact analysis, queries and reporting simpler :)
peter
On 2/27/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
Suggest away.
Mark
Michael Neale wrote:
Guys - are there going to be any changes to the compiler API now? Cause
now is the time to fix/change it if needed.
I have some suggestions if anyone is interested.
------------------------------
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
7:36 p.m.
Or, should we change the descrs to look like that?
how does that relate to the descrs?
On 2/28/07, Peter Lin <woolfel(a)gmail.com> wrote:
although drools-compiler has the descr classes, it would be nice to have
an Rule Object Model like the one I showed you guys.
this way, a condition would be represented by a condition object like this
public class Condition {
/**
* Added the attribute to make it easier to compile the rule to
* java code
*/
private String objectType;
/**
* if the attribute is bound to a variable, the method
* should return the name of the variable.
*/
private String boundVariable;
/**
* the attribute of the object to match on
*/
private String attribute;
/**
* the operator for the condition, which may be ==, !=
* <, >, <=, >=, <>
*/
private String operator;
/**
* The timestamp of the last change made to the condition.
* this attribute is optional and is meant to make it
* easier to run queries on the rules by timestamp
*/
private long timestamp;
/**
* the value of the condition
*/
private String value;
/**
* the value can be either a single literal value or a list
* of values of the same type
*/
private String valueType = null;
/**
* the version of the condition. for advanced reporting, it's
* easier if the condition is tagged with a version number.
*/
private String version;
}
I'm totally bias, but it would make writing tools easier. things like rule
repo, validation, impact analysis, queries and reporting simpler :)
peter
On 2/27/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
>
> Suggest away.
>
> Mark
> Michael Neale wrote:
>
> Guys - are there going to be any changes to the compiler API now? Cause
> now is the time to fix/change it if needed.
>
> I have some suggestions if anyone is interested.
>
> ------------------------------
>
> _______________________________________________
> rules-dev mailing list
>
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
8 p.m.
what i mean was to flatten the model so that instead of having the
information spread over a bunch of descr classes, the representation is
flatter and simpler.
makes analyzing the rules before compilation easier.
peter
On 2/27/07, Michael Neale <michael.neale(a)gmail.com> wrote:
Or, should we change the descrs to look like that?
how does that relate to the descrs?
On 2/28/07, Peter Lin < woolfel(a)gmail.com> wrote:
>
>
> although drools-compiler has the descr classes, it would be nice to have
> an Rule Object Model like the one I showed you guys.
>
> this way, a condition would be represented by a condition object like
> this
>
> public class Condition {
>
> /**
> * Added the attribute to make it easier to compile the rule to
> * java code
> */
> private String objectType;
> /**
> * if the attribute is bound to a variable, the method
> * should return the name of the variable.
> */
> private String boundVariable;
> /**
> * the attribute of the object to match on
> */
> private String attribute;
> /**
> * the operator for the condition, which may be ==, !=
> * <, >, <=, >=, <>
> */
> private String operator;
> /**
> * The timestamp of the last change made to the condition.
> * this attribute is optional and is meant to make it
> * easier to run queries on the rules by timestamp
> */
> private long timestamp;
> /**
> * the value of the condition
> */
> private String value;
> /**
> * the value can be either a single literal value or a list
> * of values of the same type
> */
> private String valueType = null;
> /**
> * the version of the condition. for advanced reporting, it's
> * easier if the condition is tagged with a version number.
> */
> private String version;
> }
>
> I'm totally bias, but it would make writing tools easier. things like
> rule repo, validation, impact analysis, queries and reporting simpler :)
>
>
> peter
>
> On 2/27/07, Mark Proctor < mproctor(a)codehaus.org> wrote:
> >
> > Suggest away.
> >
> > Mark
> > Michael Neale wrote:
> >
> > Guys - are there going to be any changes to the compiler API now?
> > Cause now is the time to fix/change it if needed.
> >
> > I have some suggestions if anyone is interested.
> >
> > ------------------------------
> >
> > _______________________________________________
> > rules-dev mailing list
> >
> >
> > rules-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> >
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
9:07 p.m.
* Firstly, a simpler higher level API, like the RuleBaseLoader - for dealing
with simple cases (a High Level API that compiles and builds in one step).
* Secondly - I don't see why we have to expose the descrs in the normal case
- we can just have an api that goes from source to Package binary - make it
optional to extract the Descrs.
* Perhaps something like:
PackageBuilder.addPackageHeader(... stuff for package header... only done
once... eg globals, imports... validate it all at this point).
PackageBuilder.addRule(... just takes the reader to a single rule...)
PackageBuilder.addDrl(... just takes a reader to a chunk of DRL, but does
NOT include the package header? Or if it does, it works jsut as before,
merging the package).
PackageBuilder.addFunction...
you get the idea. Its really augmenting it for the repo/individual rule
assets/files.
On 2/28/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
Suggest away.
Mark
Michael Neale wrote:
Guys - are there going to be any changes to the compiler API now? Cause
now is the time to fix/change it if needed.
I have some suggestions if anyone is interested.
------------------------------
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6508
days inactive
6508
days old
5 comments
3 participants
participants (3)
-
Mark Proctor -
Michael Neale -
Peter Lin