Note: You are currently viewing documentation for Moodle 3.3. Up-to-date documentation for the latest stable version of Moodle is probably available here: Navigation 2.0 implementation plan.

Development:Navigation 2.0 implementation plan

From MoodleDocs
Revision as of 06:47, 2 April 2009 by Tim Hunt (talk | contribs)

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.


Template: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?.

  • 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

Template:CategoryDeveloper