Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Talk:Event 2: Difference between revisions

From MoodleDocs
No edit summary
No edit summary
Line 17: Line 17:


-- [[User:Marina Glancy|Marina Glancy]] 12:26, 21 May 2013 (WST)
-- [[User:Marina Glancy|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

Revision as of 04:45, 21 May 2013

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