Here's my 2 cents - as a non-contributor to Drools
codebase ;-)
You could add insertEventFactTypeThingie to the
API? Then you need just
check that the class has been declared as an event
in the DRL similar to
what must already happen for normal DRL imports. I
personally don't have
issue with implementing a marker interface (this is
what frameworks like
Hibernate, EJB3 and Spring etc have been imposing
for years). What "wiring"
does the POJO need to become an Event for use in
Drools? Are you trying to
internalise too much at the risk of making the
event mechanism inflexible?
Cheers,
Mike
-----Original Message-----
Sent: 08 November 2007 13:09
Subject: Re: [rules-dev] Determining if a class is
an event or not
Edson Tirelli <tirelli <at> post.com>
writes:
All, I reached a
point where I need to make a design decision and
would
like your opinion about it. Imagine the following scenario:
A user has a
domain model like this:package a.b.c
;public interface Event { ... }package
x.y.z;public class MyEvent
implements
a.b.c.Event {...} Then, in his DRL file he
writes:package p.q.r;import
event
a.b.c.*;
rule Xwhen
Event( ... )then
...end So, it is
clear that a.b.c.Event should
be
handled as an event by the engine. At runtime, the user asserts an
object
of
the class x.y.z.MyEvent into the working memory.
Seems clear to me (and
probably
to the user) that MyEvent should be handled as an
event, since by DRL
semantics,
a.b.c.* are all events, and by OO class hierarchy
concept, since
a.b.c.Event
is an event, x.y.z.MyEvent is an event too. My question is: how the
engine
knows that MyEvent is an event, since it only has
the x.y.z.MyEvent
class as input? The only answer I have is that
when the first MyEvent
instance is asserted into the working memory, we
must get the class name and
iterate over all event import declarations checking
for a match. In case no
one
is found, we need to repeat the process for each
interface and each class up
in
the MyEvent hierarchy. Once this process is
complete, we cache the results
in
the ObjectTypeConf.
This may be a quite heavy process to be executed each time a fact
of a
different class is asserted in the working memory
for the first time, but I
can't think a different user-friendly way to solve
the question.
The alternatives would be intrusive, IMO, breaking the drools
premise
to
work with user-defined POJOs as facts: use
anotations to annotate classes
that
are events, or mandate users implement a specific
interface for events.
Any better idea?
[]s
Edson --
Edson Tirelli Software
Engineer
- JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
9287-5646
JBoss, a division of Red Hat
<at>
www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
Edson,
I got your striving not to mandate users implement
a specific interface for
events. However, why not at least introducing an
empty event interface (i.e.
a
marker interface, similar to the Serializable
interface in Java) the
user-defined event class(es) have to implement?
This way, when inserting a
MyEvent instance, you can simply check whether it
implements the event
interface
(by means of 'instanceof'). Moreover, while parsing
the import statements of
a
rule file, it enables you to double-check whether
all the "event imports"
really
refer to classes implementing the (empty) event
interface.
In this regard, for me another question raises:
Without making any
restrictions
on the structure for a user defined event class,
how do you make sure it has
all
the
required attributes of an event (which in my opinion must be a
timestamp,
at least) and how do you access them (necessary for
temporal relationships)?
Having said this, in my opinion defining an empty
event interface may not be
sufficient; in addition, it must force the user to
implement a method
returning
the event's occurrence date (i.e. the timestamp) at
least... Or how would
you
handle this issue?
Matthias
_______________________________________________
rules-dev mailing list
_______________________________________________
rules-dev mailing list