-
Improvement
-
Resolution: Fixed
-
Minor
-
None
-
1.8, 1.9
-
None
-
MOODLE_18_STABLE, MOODLE_19_STABLE
More Pluggable Course Formats:
Currently, we can -
- display a course page's content the way we want using '/course/format/[myformat]/format.php
- limit and control block display through the config.php
- add format specific language strings through course format language files
- add and manage speicific database tables and fields
- manage backup and restore for specific format needs
- define new roles and capabilities
- define course format specific styles
Limitations -
Display:
- can't control the header or footer output - these are output by the main /course/view.php
Function:
- a number of arguments are handled in the main /course/view.php (eg. hide and show) that may wish to be handled differently
- all functions are in the main /course/lib.php - there is no way to replace them (we can force our own in the format.php, but that won't prevent the standard ones from being executed which can affect execution resources)
Course Settings:
- while we can add our own data tables, we cannot change the course settings page to use any specific new settings
Proposed Changes:
- create a simple class file (course_format.class.php), that can be extended by any course format
- break the current /course/view.php file into extensible pieces, and create extensible methods (where appropriate)
> current layout -
1. File inclusion - keep
2. Argument loading - keep, although some of these should really be moved to specific formats
3. Course data validation - keep,
4. Login Access control - extensible?
5. Page setup and section argument handling - extensible
6. Ajax setup - extensible
7. Module and section setup - extensible
8. Output - header, page, Ajax scripts, footer - extensible - change the course/view.php to use these methods, and look for existing extended class types in the specific format directories
- the 'view' method will do step 8, which will work 'as is' for all existing formats
- leave all existing course/lib.php functions where they are - they don't need to be part of the class for now, but all formats can use their own by adding to their own class files
- the biggest issue here is with the use of variables created in /course/view.php and used in the 'format.php' files (by inclusion). Make sure the base course_format class globalizes these. Currently, these are:
$section (from arguments)
$marker (from arguments)
$course (still presumed global?)
$PAGE
$pageblocks
$mods, $modnames, $modnamesplural, $modnamesused - used as globals
$sections - used as global
CUSTOM COURSE SETTINGS:
Proposal is to modify the '/course/edit.php' function to handle any extra settings provided by the format. This modification is done in such a way to work with all existing formats as is.
The changes require calling an extra (optional) format function that provides any extra course information to the course object/record. When the standard main settings page is saved, if there is any extra settings defined in the format, then that form is displayed. That form is provided by a class function and a form class definition. The existence of these triggers the secondary settings.
- has been marked as being related by
-
MDL-35218 META: Course formats refactoring for 2.4
-
- Closed
-