Note:

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

Subplugins: Difference between revisions

From MoodleDocs
(New page: Sub plugins allow activity modules to be extended without having to change the module's code. Each activity module can define a set of subplugin types in <tt>db/subplugins.php</tt>. The ...)
 
(Fixed transposed parameters in example.)
Line 13: Line 13:


An important thing to remember when using lang strings is to prefix the component with the plugin type, as you do with all non-activity blocks.  So to print the name of the "accumulative" workshopform plugin, you'd do
An important thing to remember when using lang strings is to prefix the component with the plugin type, as you do with all non-activity blocks.  So to print the name of the "accumulative" workshopform plugin, you'd do
  print_string('workshopform_accumulative', 'pluginname');
  print_string('pluginname', 'workshopform_accumulative');

Revision as of 13:45, 23 March 2011

Sub plugins allow activity modules to be extended without having to change the module's code.

Each activity module can define a set of subplugin types in db/subplugins.php. The file must contain an array called $subplugins, with the plugin type as the key for the directory containing the plugins. For example, from mod/workshop/db/subplugins.php:

$subplugins = array(
                   'workshopform'       => 'mod/workshop/form',
                   'workshopallocation' => 'mod/workshop/allocation',
                   'workshopeval'       => 'mod/workshop/eval',
                   );

This defines 3 plugin types, workshopform, workshopallocation, and workshopeval. The plugins themselves can be found in mod/workshop/form, mod/workshop/allocation and mod/workshop/eval, respectively. Each of these directories can contain a number of plugins, each within it's own subdirectory.

Writing a sub-plugin

A sub-plugin has the same structure as a regular plugin. It will have a version.php, a lang directory, and can have a db directory with an install.xml and all the other hooks you'd expect to see used in any other type of plugin, such as an activity, block, or admin report.

An important thing to remember when using lang strings is to prefix the component with the plugin type, as you do with all non-activity blocks. So to print the name of the "accumulative" workshopform plugin, you'd do

print_string('pluginname', 'workshopform_accumulative');