Development:Navigation 2.0 implementation plan: Difference between revisions
(New page: TODO. Sorry ;-) busy day.) |
No edit summary |
||
Line 1: | Line 1: | ||
{{Work in progress}} | |||
{{Moodle 2.0}} | |||
This page lists the various strands of work that will be needed to implement [[Development:Navigation 2.0]] and tried to break them down into manageable chunks. | |||
==Page object== | |||
Re-purpose $PAGE. $PAGE becomes the entry point (facade) for a range of services to do with tracking the page we are on. | |||
* General information - there will be fields | |||
** $PAGE->course - alias for $COURSE. | |||
** $PAGE->context | |||
** $PAGE->url - a moodle_url object for this page. | |||
* Navigation information - probably trees of objects that describe how this page fits into the navigation hierarchy. Not quite sure how this will be populated. | |||
** $PAGE->navigation | |||
** $PAGE->settingspages | |||
* Other stuff, see below. | |||
==JavaScript cleanup== | |||
* New class requirements_manager, accessible via $PAGE->requires. | |||
* Replaces require_js and friends with methods like | |||
** $PAGE->requires->js('mod/mymod/script.js'); | |||
** $PAGE->requires->css('mod/mymod/styles.css'); | |||
** $PAGE->requires->call_js($fnname, $arguments); | |||
** $PAGE->requires->string_for_js(); | |||
** $PAGE->requires->data_for_js(); | |||
* Nomally (apart from CSS) these requirements are output at the foot of the page. To override that and output the associated HTML as soon as possible, you can do | |||
** $PAGE->requires->js('mod/mymod/script.js')->immediately(); but this is not recommended and normally not necessary. | |||
** $PAGE->requires->call_js('init_my_feature')->on_dom_ready(); | |||
* requirements_manager tracks what needs to be linked to, and whether a link has been output yet. | |||
* print_footer and print_header call it get extra HTML to output. | |||
* keep a deprecated require_js function for backwards compatibility. | |||
There is then just a the small matter of converting all the legacy JS inclusion to user the new API to include itself. | |||
==Filters== | |||
Implement [[Development:Filter enable/disable by context]]. | |||
* Create moodle/filter:manage capability. | |||
* Create DB filter_active table. | |||
* Upgrade existing $CFG->filters into that table. | |||
* Update admin page to work with the settings table. | |||
* New settings page for other contexts. | |||
* New get_active_filters($context); function. | |||
* Backup and restore new settings. | |||
==Themability== | |||
See [[Development:Theme_engines_for_Moodle%3F]]. | |||
* Think about a consistent way to do the paramenter lists of all the print_xxx methods in weblib.php. | |||
* New global object $OUT with two responsibiltites | |||
* ... | |||
==Blocks management== | |||
==Navigation== | |||
==See also== | |||
{{CategoryDeveloper}} |
Revision as of 06:47, 2 April 2009
Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please [ http://moodle.org/course/view.php?id=5 join the discussion on moodle.org] or use the page comments.
This page lists the various strands of work that will be needed to implement Development:Navigation 2.0 and tried to break them down into manageable chunks.
Page object
Re-purpose $PAGE. $PAGE becomes the entry point (facade) for a range of services to do with tracking the page we are on.
- General information - there will be fields
- $PAGE->course - alias for $COURSE.
- $PAGE->context
- $PAGE->url - a moodle_url object for this page.
- Navigation information - probably trees of objects that describe how this page fits into the navigation hierarchy. Not quite sure how this will be populated.
- $PAGE->navigation
- $PAGE->settingspages
- Other stuff, see below.
JavaScript cleanup
- New class requirements_manager, accessible via $PAGE->requires.
- Replaces require_js and friends with methods like
- $PAGE->requires->js('mod/mymod/script.js');
- $PAGE->requires->css('mod/mymod/styles.css');
- $PAGE->requires->call_js($fnname, $arguments);
- $PAGE->requires->string_for_js();
- $PAGE->requires->data_for_js();
- Nomally (apart from CSS) these requirements are output at the foot of the page. To override that and output the associated HTML as soon as possible, you can do
- $PAGE->requires->js('mod/mymod/script.js')->immediately(); but this is not recommended and normally not necessary.
- $PAGE->requires->call_js('init_my_feature')->on_dom_ready();
- requirements_manager tracks what needs to be linked to, and whether a link has been output yet.
- print_footer and print_header call it get extra HTML to output.
- keep a deprecated require_js function for backwards compatibility.
There is then just a the small matter of converting all the legacy JS inclusion to user the new API to include itself.
Filters
Implement Development:Filter enable/disable by context.
- Create moodle/filter:manage capability.
- Create DB filter_active table.
- Upgrade existing $CFG->filters into that table.
- Update admin page to work with the settings table.
- New settings page for other contexts.
- New get_active_filters($context); function.
- Backup and restore new settings.
Themability
See Development:Theme_engines_for_Moodle?.
- Think about a consistent way to do the paramenter lists of all the print_xxx methods in weblib.php.
- New global object $OUT with two responsibiltites
- ...