[rules-dev] Determining if a class is an event or not

[Felipe Piccolini]

Well,

   IMHO for the experience I have I suggest to implement both solutions:
	-an API insertEvet() so the user can implement the mechanism to manage
their rules knowing when a fact is an event or not.
	-an Interface Event so when the user cant manage the flow asserting  
facts, when
he cant know when a fact is or not an event, then maybe he can wrap  
some facts on this
interface and the API insert() internaly can check if the fact is an  
event or not and call insertEvent if
necesary.

:)

On 08-11-2007, at 11:27, Anstis, Michael ((M.)) wrote:

> 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-----
> From: rules-dev-bounces at lists.jboss.org
> [mailto:rules-dev-bounces at lists.jboss.org] On Behalf Of Matthias
> Sent: 08 November 2007 13:09
> To: rules-dev at lists.jboss.org
> 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
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
> 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 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


Felipe Piccolini M.
felipe.piccolini at bluesoft.cl




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20071112/dcf27f69/attachment.html