Re: [drools-user] Using my own Extractor Factory?

[Edson Tirelli]

  Mark,
  For now you have to do as Michael said, but trunk already has (for 
the next version) the "from" operator:

when
  Foo( tuo == "..." ) from Bar.getFoo()
then.
 ...
end

  []s
  Edson

Michael Neale wrote:

You cant yet do anything like:

Bar(foo.tuo == "...")

but you can do
Bar($foo: foo)
eval($foo.getTuo().equals("..."))

I think its a seperate problem.

On 10/27/06, *Mark Emeny* <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:

    Is this not similar in principle to my problem, where I do have
    simple getters but those getters return an object reference that
    I'd like to run a rule against?

     

    For example:

     

    public class Bar {

                private Foo foo;

    public Foo getFoo() { return foo; }

    }

     

    public class Foo {

                private String tuo;

                public String getTuo() { return tuo; }

    }

     

    Am I right in saying I can't create a constraint based on the
    value of "tuo"?

    ------------------------------------------------------------------------

    *From:* Michael Neale [mailto:[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>]
    *Sent:* 27 October 2006 11:08
    *To:* user@drools.codehaus.org <mailto:user@drools.codehaus.org>
    *Subject:* Re: [drools-user] Using my own Extractor Factory?

     

    You have understood shadows, yes.

    For your "getters" - it doesn't look like anything remotely
    follows the java bean standard? And there is no instance method on
    a class which returns a value? ie does everything have to come
    from a static method like that?

    On 10/27/06, *Trevor Pocock* <[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>> wrote:

    Hallo Edson

    Im not going to pretend i understand all the details about the
    shadow facts, but
    i think you mean there needs to be a layer between the asserted
    beans and the
    engine to control when changes to the beans have an effect upon
    the engine, e.g. with

    then
       $foo.setBar(123)
       ...

    the change to the Foo is currently immediate, but this causes
    problems,
    so the aim is to make the change visible after the rule ends (or if
    modify(foo) is called?)

    A little bit about "our" getters (we have a license to use the system,
    so i cant distribute everything). The reason i thought about them
    looking at your extractor factory, is that they in some ways touch on
    the same ideas. As far as i see, you have a set of extractor classes,
    each with a method like

    Object getValue(Object owner)

    and the factory is responsible for creating an instance of the right
    extractor class based on the type of the field being extracted (int,
    double, boolean, Object)

    "our" system allows you to have any number of "getter" classes which
    have at the heart a similar getValue(Object owner) method. Here in
    a much
    simplified form:

    interface Getter {
      Object get(Object owner);
    }

    interface IntegerGetter entends Getter {
      Integer getValue(Owner owner);
    }

    interface ObjectGetter entends Getter {
      Object getValue(Owner owner);
    }

    class Foo {

    int bar;
    public static IntegerGetter barGetter =
         new IntegerGetterImpl(Foo.class, "bar" ..type info etc..);

    }

    some client {
    ...
    Foo myFoo;
    Integer bar = Foo.barGetter.getValue(myFoo);
    ...
    }

    One such Getter class allows any number of object getters to be
    chained together to form a path so you can define lookups over
    relationships, e.g. imagine a

    class Zop {
      Foo zopsFoo;
      public static ObjectGetter zopGetter =
        new ObjectGetterAdapter(Zop.class, "zopsFoo" ..type info etc..);
    }

    some client {
    ...
    Zop myZop;
    IntegerGetterChain myPath =
        new GetterChain().add(Zop.zopGetter).add(Foo.barGetter);
    Integer bar = myPath.getValue(myZop);
    ...
    }

    We make use of the getters in almost every level of our eclipse
    rich client/app server/database application

    Trevor





    ---------------------------------------------------------------------
    To unsubscribe from this list please visit:

        http://xircles.codehaus.org/manage_email
    <http://xircles.codehaus.org/manage_email>

     




---------------------------------------------------------------------
To unsubscribe from this list please visit:

   http://xircles.codehaus.org/manage_email