Hi Hubert,
I discussed it with Martin at the Perth hackfest and he agreed that we should write it with the intention of it going into core, instead of as a local plugin.
If that's not the case it would be good to know sooner rather than later as Yuliya has started development already.
Assuming it is accepted as core, is it preferred to embed a hook into the right place (as seems to be recommended in the comments), or to use event triggers (as done by course completion for example)?
Simon
I'd say event triggers would be ideal - this way we can use those same events for other stuff - looks like the new logging api stuff will be using event style functions too - so I think it makes sense for generic hooks to go in place (using events) rather than specific badge hooks.
Just because something is going to become part of the standard Moodle download, you should still create it as one of more instances of standard types of plugin if you can.
Exactly. There is a difference between shipping with core Moodle, and intermingling with the core libraries. In general, the core libraries should be kept as generic as possible -- unless there is a specific reason (e.g. severe performance degradation), modifications should be made in such a way that it can be used by multiple things, rather than being single purpose.
(By the way, I'm glad that someone is working on OpenBadges support.)
I agree with the principle, but I'm not sure how to achieve it in this particular case.
The issue is that open badges need to be awardable across courses, or for things unrelated to any course, so an activity module doesn't seem appropriate since you don't have open badge "instances" which belong to a course. We do intend to create a block for some of the functionality but again it doesn't seem appropriate for everything.
The approach we're taking (which seems to be the way core features like completion, blog or grade do it) is to try to keep the code as separate as possible (within it's own directory and library file), but still use lib/db/ for code upgrades etc.
Personally I wish that core features were more isolated from each other - if there was a "core" plugin type with each feature having it's own "core/[componentname]/db/ directory" rather than having it all together in lib/db/ it would result in less conflicts when merging in changes.
Given that's not how it's done at the moment are there any other plugin types which are appropriate for a feature that's acting at the site level?
Simon
Report plugin, maybe? (Though, can report plugins create database tables?)
"(Though, can report plugins create database tables?)"
They can.
I would like even more events added to Moodle so that other plugin developers can better tie into Moodle. For example, we are adding a grade_grade_updated and grade_item_updated events that the activity completion component should be using, rather than inserting itself into the gradebook directly.
But that is a core hack we needed to do. With the Logging improvements spec that was developed at the Hackfest, it is proposing to use the events api to replace the add_to_log method calls. So any work you can do with tying into the events api can only help later down the road.
Yes good point Rex and Dan regarding the logging API.
The only question then is why this comment appears in lib/db/events.php:
/* no more here please, core should not consume any events!!!!!!! */
Maybe I should ask Petr as he added that comment.
Simon