Note:

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

Hooks spec: Difference between revisions

From MoodleDocs
Line 19: Line 19:
== Implementation ==
== Implementation ==


* All hooks/features definitions are stored in /db/ folder (of core or plugin). It's best to implement definitions as interfaces or parent classes, this way PHP will make sure that implementations exactly match the definition.
Very similar to [https://docs.moodle.org/dev/Events_API|Events] but with much less restrictions and more flexibility


* All implementations are also stored in plugin in particular place. Maybe folder /hooks/ or /features/ or specific file(s) name(s).
* Hook definition is a class stored in /classes/hook/ folder (of core component or plugin). They have a function execute() that calls all registered listeners and passes the actual instance of the hook definition class to them.  


* The definitions and implementations are analysed during install/upgrade only. They are stored in DB, so we include files when and only when we need them.
* Plugins that want to register hook listener/observer do so in /db/hook.php the same way events do


* There is an administrative management interface that allows to review all available implementations, prioritise and/or disable them. By default the implementations are disabled but admin receives a notification during install/upgrade that new implementations are available and may be enabled.
* Hook manager, very similar to event manager, is responsible for caching the list of existing hooks and their listeners. It also has an interface with list of all hooks and listeners


== Use cases ==
== Use cases ==

Revision as of 01:14, 12 February 2014

Moodle hooks/features (Proposal)

Summary

Allow plugins to substitute or extend some core code where change is not big enough to create a new plugin type but we want to allow plugins interactions. Create management UI where admin can see the list of all available hooks/features definitions and available implementations, enable/prioritise implementations.

Current solutions

  • Renderers. These can be used to override a lot of standard Moodle behaviour, particularly on the view side. They can be abused to override even more.
  • Events system. The core notifies whoever wants to listen to it about something that happens. Disadvantage: one-way communication, no feedback. Advantage: plugins cannot break important core functionality.
  • Defining functions in /plugindir/lib.php with the name <pluginname>_<hookname> and querying all plugins if somebody implements function and/or list of plugins implementing it. Disadvantage: functions must be defined in lib.php therefore they are always included (performance loss); no UI to configure if only one plugin can implement feature; difficult for developers because they don't know if they can or how they can implement a hook.
  • $CFG variables. Disadvantage: they should be used for settings and not for including the 3rd party code
  • Creating a new plugin type. Disadvantage: very long process, involves lots of documentation, creating lots of strings and UI, may be available in major releases only. Also not applicable for minor features.

Implementation

Very similar to [1] but with much less restrictions and more flexibility

  • Hook definition is a class stored in /classes/hook/ folder (of core component or plugin). They have a function execute() that calls all registered listeners and passes the actual instance of the hook definition class to them.
  • Plugins that want to register hook listener/observer do so in /db/hook.php the same way events do
  • Hook manager, very similar to event manager, is responsible for caching the list of existing hooks and their listeners. It also has an interface with list of all hooks and listeners

Use cases

  1. Course search: we have quite primitive course search algorithm in core. Some other plugin may implement search with sorting by relevance, analysing tags, going through attached pdf files, etc. Hook implementation returns the list of courses and core goes back to the core/theme renderers to display this list
  2. Global search: similar to above but result will be list of title+url+abstract
  3. Front page: We have $CFG->customfrontpageinclude for including a file displaying frontpage contents. It could be also hook/feature
  4. Extending mimetypes list
  5. Extending licenses list
  6. Logging (instead of using events functionality)
  7. Adding fields to the standard forms. This may be a comprehensive feature that includes several functions - adding fields, validation, processing.
  8. Hooking into backup/restore process. Example when plugin wants to add some field to the course, for example "classroom", and make sure that it is backed up/restored.