Issue #SCB2796 () Event Handlers i nScarab

Activity report on

  *Enhancement SCB2796 - Event Handlers i nScarab*

  Scarab Link: http://www.solitone.org/scarab/issues/id/SCB2796
  Module: Scarab


  Activity generated by Hussayn Dabbous ([email protected]) at 01/16/2009 00:48

  *Reasons for the changes*


  *Comments*
  - By Hussayn Dabbous - 01/16/2009 00:48 ---
  "== For what are EventHandlers used ?

 EventHandlers react on changes of Attribute Values. Whenever an Attribute value
 changes, the associated EventHandler is triggered. Depending on the nature
 of the handler, different activities can be performed, like:

 starting a timer (usefull for watchdogs) \\
 modifying another attributes value\\
 send a notification to an external application\\
 ...\\

== How are EventHandlers defined ?

 EventHandler is an Interface. Every class, which implements the EventHandler \\
 interface can be used as EventHandler during runtime.

== How are Attributes associated to EventHandlers?

 There is a Selector-box in the Attribute-Editor. The selector-box contains a set\\
 of predefined system EventHandlers. Furthermore, since EventHandler\\
 is an Interface, customized EventHandlers may be added to Scarab as needed. \\
 The list of available EventHandler implementations is generated during runtime \\
 (using reflection?, every class that implements org.tigris.scarab.event.EventHandler\\ 
 is added to the list on startup)

== What data is available for EventHandlers ?

When an EventHandler is associated to an Attribute, we can add a Property container \\
containing static data plus dynamic ${variables}  which will be filled during runtime.\\
When an EventHandler actually does something, it will get a context containing the\\
mentioned set of properties plus a reference to an associated Issue. The EventHandler\\ 
can read and modify the Issue Content if needed.

== When does an EventHandler get instanciated and how does this happen exactly ?

Whenever an issue is modified, each modified attribute is checked for associated event handlers.\\
If an EventHandler association is found, an EventHandlerTable is queried for an Entry with the\\
keys:

** ISSUE_ID
** MODULE_ID      (maybe redundant, can't we get the moduleId from the issue ?)
** ATTRIBUTE_ID
** ISSUETYPE_ID  (i think we need the IssueType to find the correct attribute ...)

If such an entry exists, an EventHandler of the correct type is created, instanciated \\ with the available data and its interrupt() method is called. There are following additional \\ fields in the table mentioned above:

**   LAST_CALL_TIME (when the eventHandler was runing the last time, we don't realy need this?)\\
**   NEXT_CALL_TIME (a wakeup time for the EventHandler. At that time it will be called again)\\

   After performing its task, an eventhandler may remove its own entry from\\ 
   the EventHandlerTable. Or it may set a rewake time (NEXT_CALL_TIME).

If no entry exists in the EventHandlerTable, an EventHandler of the correct type is\\ created, instanciated with the available data and triggered to run(). An EventHandler \\ may decide to get recalled later. In that case, it must create an entry in \\ the EventHandlerTable and set the NEXT_CALL_TIME to a value in the future.

== Who exactly triggers an EventHandler to run() or rerun() ?

# From the IssueEditor\\
     Whenever an attribute value is changed online
# Form the EventHandlerManager\\
     Whenever the NEXT_CALL_TIME is reached for an EventHandler
"

------------------------------------------------------
http://scarab.tigris.org/ds/viewMessage.do?dsForumId=458&dsMessageId=1027426

To unsubscribe from this discussion, e-mail: [[email protected]].