Development:Navigation 2.0 implementation plan

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.

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.

I think the aim is for me to do as much as this as possible during the 13 weeks I am still working for moodle.com. Therefore, I have focussed on the core work it is necessary to do to achieve the core goals, and then noted ways we could do more later as 'Future ideas'.

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.
  • $PAGE->lang
  • $PAGE->theme

• 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->navbar - a more OO approach to the navigation bar
  • $PAGE->settingspages - behind the scenes links (like roles, settings, filter, files) that relate to this context.
  • $PAGE->globalnav - how this page fits into the global navigation structure.

• Other stuff, see below.

Estimates:

• Document the sequence in which things get set up during the start of any Moodle page (from require_once('config.php'); to require_login(), or so, showing where all the globals get set up. Both the current flow, and the propsed new order: 2 days
• Based on that implement the basic information storage role of $PAGE, and kill the existing $PAGE subclasses, moving any important code elsewhere: 1 week, but depends on the previous task.

The other roles of $PAGE are covered below, I think.

Themability

See Development:Theme_engines_for_Moodle?.

• Devise a consistent way to manage the parameter lists of all the print_xxx methods in weblib.php, so that we don't have to have functions with millions of parameters: 1 day.
• New moodle_core_renderer class and a global instance $OUT, and make deprecated versions of all the old weblib.php functions that delegate to it. 1+ week
• Implement default_renderer_factory, with the option for themes to specify a different renderer factory in their config.php. The current renderer factory will be accessible as $PAGE->theme, as in $PAGE->theme->get_renderer('forum'); 1- week
• Create

Navigation

Miscellaneous revant bugs

• MDL-14632 Increase use of tabs on all mod activities - that summary is no longer what we are planning.
• MDL-2347 Admin option to automatically list course categories in the nav bar.
• MDL-8369 Folder-like presentation of the courses at the main page

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.

Estimates:

• Tracking bug: MDL-16583
• MDL-16151, MDL-16695, MDL-16693 Building the requirements_manager class, as above and hooking it up: 1 week
• MDL-14542 give blocks, filters, etc. a sensible opportunity to call require->js and require->css: 1 day
• MDL-16673, MDL-16703, MDL-16704, MDL-16706, MDL-17922, ... Cleaning up the legacy mess: inteterminate, but a lot could be done in 2 weeks

Future ideas:

• MDL-10932 conditional get support for stylesheets.
• Extend requirements_manager so it could automatically concatenate CSS and JS into fewer larger files. (This could be done on upgrade and install.) Then serve the appropriate concatenation instead of many separate files, which is better for performance.
• Investigate open source CSS and JS minifiers, that could be used in in combination with the above.

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.
• Update caching key in format_text.
• Backup and restore new settings.

Estimate:

• ✔MDL-7336 Building the requirements_manager manager class, as above and hooking it up: 1 week Done, will be committed after code review.