Perth Hackfest October 2012/Plugin framework

• Optional base class
• New developers have more of a template to follow
• Template should encourage web services (make it easier)
• Candidates
  • Activity modules
  • Reports
  • Admin tools
  • Local plugins
  • (???) Themes
• What are we talking about?
  • Replacing just lib.php and callbacks into a class that you extend
  • Good examples: blocks, question types, repositories,
• How are we going to do backwards compatibility
  • Something like course formats
  • Need a long bridge
  • Plugins that want to use new features would need to be converted to new plugin framework
  • Look into lib/pluginlib.php
• Spec Contributors
  • Damyon
  • Mike
  • David Mudrak

lib/pluginlib.php contains simple framework perhaps suitable for cases such as local plugins and admin tools.

Writing docs and ensuring everything is covered well is an option. Decided using a class structure still provided a better solution, allowing quicker development of plugins.

Properly structured base classes would be essential.

Pluginlib really provides plugin meta data and is not really the plugin itself.

What is the real value in converting the simple plugin types, local/admin tools, there ties to moodle core is minimal.

Navigation is on example of the required core callbacks, and there was an example in the previous days session wherein there was one person unaware of such callbacks.

Where should base classes live, blocks/block_class.php

Perhaps mod/assign/mod_assign_pluginbase.php

Not really lib.php?

Having an API with one class for your interactions with the outside world and separating your plugins primary functionality.

What about a generic plugin type? Blue skies, further from what Moodle is.

Backwards compatibility is crucial.

Legacy class for dealing with old modules.

All core code looking for new API. New API calls legacy class.

Importance of documentation is still crucial as is the order in which this would be tackled.

Work on some modules while defining the base class.

Convert the rest of the core, writing docs as you progress.

Do we trouble with a NEWPLUGIN example?

• As an example sure.
• Must be kept up to date
• Documentation + tutorial.

Optional plugin features: covered by separate classes, backup and restore for example.

Some features will require legacy clases some will not, request should probably result null when no suitable class.

Q: Possibly rather than having separate classes for plugin features we could use interfaces to load a combination of functionality into a class.

- Thinking about it this would lead to libraries needing to be included in situation they are not needed because

Action items:

- Web services:

run php script that generate a db/services.php and externallib.php from the annotated @webservice local plugin lib functions that the developer wish to expose. The template will explain what/how to complete (HQ)

- new module:

need review (HQ)

- need more brainstorming in general