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)