Difference between revisions of "Events API"

Jump to: navigation, search
m (cat edit)
m (Handling an event)
Line 33: Line 33:
 
Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):
 
Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):
  
           include_once($CFG->dirroot.$handers['grade_updated']['file'];
+
           include_once($CFG->dirroot.$handlers['grade_updated']['file']);
           call_user_func($hadnlers['grade_updated']['function'], $eventdata);
+
           call_user_func($handlers['grade_updated']['function'], $eventdata);
  
 
All plugins in Moodle have access to this and can this easily “hook in” to 'grade_updated' events (and of course any other events).
 
All plugins in Moodle have access to this and can this easily “hook in” to 'grade_updated' events (and of course any other events).

Revision as of 20:13, 12 July 2007

The Events API is a new core system in Moodle to allow better communication between modules. It's based on modules triggering new events with attached data, and the other modules handling those events with custom functions.

Overview

We'll be using the example of a grade being posted from a module into the new gradebook in Moodle 1.9, but there are obviously all kinds of events possible.

Triggering an event

Whenever a grade is created or changed by a module, it should “tell” the system about it (in addition to any local working storage it uses). So, using the quiz as an example, we first define an object as follows:

$eventdata = new object();
$eventdata->itemid = $grade_item->id;
$eventdata->userid = $USER->id;
$eventdata->gradevalue = $currentvalue;

Then we post the object as an event and forget about it:

events_trigger('grade_updated', $eventdata);

Handling an event

Modules can define an events.php in their db directory which defines events they want to be notified about, and describes which of their functions or class methods should be notified. For example, an export plugin could register something like:

$handlers = array (
    'grade_updated' => array (
        'handlerfile'      => '/grade/export/banner/lib.php',
        'handlerfunction'  => 'banner_handle_grade_test',    // argument to call_user_func(), could be an array
        'schedule'         => 'cron'
    ) 
);

These are parsed during install / upgrade and stored in a simple database table.

Then, when a grade_added event happens, all the registered functions for that event will be called something like this (but with more error handling):

         include_once($CFG->dirroot.$handlers['grade_updated']['file']);
         call_user_func($handlers['grade_updated']['function'], $eventdata);

All plugins in Moodle have access to this and can this easily “hook in” to 'grade_updated' events (and of course any other events).

Database structure

There are 3 core tables for events. Note that if a handler is queued, and yet to be processed or processing failed, then all subsequent calls on that handler must be queued.

events_handlers

This table is for storing which components requests what type of event, and the location of the responsible handlers. For example, the grade book can register 'grade_added' event with a function add_grade() that should be called event time an 'grade_added' event is triggered by a module.

These entries are created by parsing events.php files in all the modules, and can be rebuilt any time (during an upgrade, say).

Field Type Info
id int(10) auto increment identifier
eventname varchar(255) name of the event, e.g. 'grade_updated'
handlermodule varchar(255) e.g. moodle, mod/forum, block/rss_client
handlerfile varchar(255) path to the file of the function, eg /grade/export/lib.php
handlerfunction text serialized string or array describing function, suitable to be passed to call_user_func()
schedule varchar(255) 'cron' or 'instant'.
status int(10) number of failed attempts to process this handler

events_queue

This table is for storing queued events. It stores only one copy of the eventdata here, and entries from this table are being references by the events_queue_handlers table.

Field Type Info
id int(10) auto increment identifier
eventdata longtext serialized version of the data object passed to the event handler.
stackdump text serialized debug_backtrace showing where the event was fired from
userid int(10) $USER->id when the event was fired
timecreated int(10) time stamp of the first time this was added

events_queue_handlers

This is the list of queued handlers for processing. The event object is retrieved from the events_queue table. When no further reference is made to the events_queue table, the corresponding entry in the events_queue table should be deleted. Entry should get deleted (?) after a successful event processing by the specified handler. The status field keeps track of failures, after it gets to a certain number (eg 10?) it should trigger an "event failed" event (that could result in admin being emailed etc, or perhaps even the originating module taking care of it or rolling something back etc).

Field Type Info
id int(10) auto increment identifier
queuedeventid int(10) foreign key id corresponding to the id of the event_queues table
handlerid int(10) foreign key id corresponding to the id of the event_handlers table
status int(10) number of failed attempts to process this handler
errormessage text if an error happened last time we tried to process this event, record it here.
timemodified int(10) time stamp of the last attempt to run this from the queue

Standards for naming events

All event names should follow a consistent naming pattern, such as modulename_noun_verb


See also