Note:

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

Navigation 2.0 implementation plan: Difference between revisions

From MoodleDocs
No edit summary
No edit summary
Line 45: Line 45:
* New settings page for other contexts.
* New settings page for other contexts.
* New get_active_filters($context); function.
* New get_active_filters($context); function.
* Update caching key in format_text.
* Backup and restore new settings.
* Backup and restore new settings.


Line 51: Line 52:
See [[Theme_engines_for_Moodle%3F]].
See [[Theme_engines_for_Moodle%3F]].


* Think about a consistent way to do the paramenter lists of all the print_xxx methods in weblib.php.
* Think about a consistent way to do the parameter lists of all the print_xxx methods in weblib.php.
* New global object $OUT with two responsibiltites
* New global object $OUT with two responsibility
* ...
* ...



Revision as of 06:48, 2 April 2009

Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.

Moodle 2.0


This page lists the various strands of work that will be needed to implement 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 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.
  • Update caching key in format_text.
  • Backup and restore new settings.

Themability

See Theme_engines_for_Moodle?.

  • Think about a consistent way to do the parameter lists of all the print_xxx methods in weblib.php.
  • New global object $OUT with two responsibility
  • ...

Blocks management

Navigation

See also

Template:CategoryDeveloper