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
In reply to Simon Coggins
Re: Events vs. function calls in Moodle Core development
by Hubert Chathi -
Report plugin, maybe? (Though, can report plugins create database tables?)
"(Though, can report plugins create database tables?)"
They can.