Talk:Event 2

Question:

Should subplugins trigger events using the name of the parent module (e.g. the assignsubmission_comments subplugin can trigger assign_submissioncommented ?)

Also - why are we assuming there is only a single subject for an event?

e.g. A teacher grades a submission - the subjects should be all of (teacher, student, assignment and submission).

-- Damyon

Damyon, anybody can trigger event defined in another place. For example plugins can trigger the core events and subplugins can trigger events defined in plugin. It's just most common the plugin who defines event triggers it.

In your case the mod_assign will define event: mod_assign_event_submission_completed and subplugins can trigger it specifying their own name as 'component' property of event.

"Teacher grades a submission": teacher is the actor, submission is a subject. Student is not really related here :)

-- Marina Glancy 12:26, 21 May 2013 (WST)

Documenting some lunch table discussions: A valid use case for the event system might be - subscribe to all events affecting this user - this is impossible with this design. Also mentioned was that for bulk actions it would be desirable to fire a bulk user enrolled event with a list of users, rather than lots of individual events - but again you want to be able to subscribe to an event that affects a single user without predetermined knowledge of all the possible event types.

-- Damyon

Big question: Why? This spec really needs an introduction to explain why you are proposing to make non-backwards-compatible changes to a bit of Moodle that currently works fine.--Tim Hunt 00:07, 22 May 2013 (WST)

Use of php autoloading

PHP __autoload is a very nice feature in PHP 5 which allows for

• Class files to be automatically loaded when needed
• Only those files that need to be included are included (a little bit of memory savings).
• Defer file inclusion to last possible moment.
• Allow registering of more than one function to load class files (Needed while using third party libraries or projects where file structure is different in different modules)
• Nice error handling can be implemented to suite special needs
• Enforce structured naming scheme throughout the project
• Prevents duplicate class name declarations from ever occurring
• Simple to use and avoid dependency tracking in large projects like moodle.

On the other hand there are few cons for using __autoload:

• Might break plugins not using structure or duplicate class names (Two plugins with same name)
• If lots of classes, calling the function, translating the names and so on usually takes longer to execute than a group of simple includes (Probably negligible but worth considering)
• Integrating third party libraries will be an overhead, if class name conflict.
• Autoloaders cannot work simultaneously, having two libraries with different structure will need the second one to wait till the first one either load the class or decide that it does not recognize the class name.
• Can cause issues with obfuscater or zend guard.

Personally for events, it might be nice to use autoload functionality, as it will avoid tracking dependency and load class when needed.

We can use PSR-0 standard or code below to achieve this.

spl_autoload_register(function ($classname) {
    global $CFG;
    if ($pluginfullname = stristr($classname, '_event_', true)) {
        $eventfile = $CFG->dirroot.'/'.str_replace('_', '/', $pluginfullname).'/events/'. str_replace($pluginfullname.'_event_', '', $classname).'.php';
        if (is_readable($eventfile)) {
            require_once $eventfile;
        }
    }
});

Current unit test for event and logging

Current Moodle code has unit test for

• events : lib/tests/eventslib_test.php
• logs : Stats unit test is making logs. lib/tests/statslib_test.php