mod form extension specification: Difference between revisions
(Created page with "This page summarises a way to extend the module creation/editing form for existing mod plugins by defining custom classes in a local plugin for Moodle 2.3 {{Moodle 2.3}} {| clas...") |
mNo edit summary |
||
Line 13: | Line 13: | ||
== Introduction == | == Introduction == | ||
One of Moodle's greatest | One of Moodle's greatest strengths is its pluggability and the wide range of plugins that have been made available for it. However, whilst some plugins are made with one set of users in mind, individual institutions may have slightly different requirements and, as such, wish to have slightly different defaults or to hide a setting from users entirely. Additionally, some institutions will want to automatically create some modules based on external data sources. Whilst this is theoretically possible with use of the cmidnumber, users can currently reset settings post-creation or synchronisation. | ||
This specification proposes an easy way of extending any installed modules mod_form to cater for these scenarios and others without making any changes to the module itself. | This specification proposes an easy way of extending any installed modules mod_form to cater for these scenarios and others without making any changes to the module itself. |
Revision as of 11:04, 24 July 2012
This page summarises a way to extend the module creation/editing form for existing mod plugins by defining custom classes in a local plugin for Moodle 2.3 Moodle 2.3
mod_form extension Specification | |
---|---|
Status | Draft |
Tracker | MDL-34509 |
Introduction
One of Moodle's greatest strengths is its pluggability and the wide range of plugins that have been made available for it. However, whilst some plugins are made with one set of users in mind, individual institutions may have slightly different requirements and, as such, wish to have slightly different defaults or to hide a setting from users entirely. Additionally, some institutions will want to automatically create some modules based on external data sources. Whilst this is theoretically possible with use of the cmidnumber, users can currently reset settings post-creation or synchronisation.
This specification proposes an easy way of extending any installed modules mod_form to cater for these scenarios and others without making any changes to the module itself.
Usage scenarios
- Administrator would like to change the default 'Prevent late submission' setting for mod_assign to 'No' (from 'Yes')
- Administrator would like to entirely hide the 'Feedback comments' setting in mod_assign and force its value to 'Yes'
- Administrator would like to set a range of default values based upon whether the cmidnumber value is set or not
Required modifications to core
In order to allow for this functionality in the least invasive way possible:
- modify course/modedit.php to load the new module form from a local plugin
- modify course/moodleform_mod.php to determine the name correctly based upon the new mod_form name
The suggested change would require that a local plugin has a file with a name based upon the modules name. That file would contain a class extending the standard class for that module.
Some examples:
Module frankenstyle name | Standard form class name | local form class name |
mod_assign | mod_assign_mod_form | local_example_mod_assign_mod_form |
mod_page | mod_page_mod_form | local_example_mod_page_mod_form |
mod_resource | mod_resource_mod_form | local_example_mod_resource_mod_form |