[rules-dev] Compiler API - changes?

[Peter Lin]

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 at 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 at 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 at 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 at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-dev
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > rules-dev mailing list
> > > rules-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-dev
> > >
> > >
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070227/bbe55b46/attachment.html