User:Andrew Nicols

Revision as of 15:43, 25 June 2013 by Andrew Nicols (talk | contribs) (Add notes on configuration)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

I am the component maintainer for AJAX and Javascript.

My thoughts on the JavaScript Roadmap for 2.6 and beyond

Move the YUI_config to YUI.GlobalConfig in a separate file

Priority: High

Target release: 2.6

Description

Move the YUI_config currently in our header to a separate (versioned) file loaded by a <script> tag.

Rationale

By moving to a separate file, we allow the browser to cache the data. The data in question is generic to every page load. We also reduce the base size of each request. At present, basic YUI config for all of our modules comes in at about 1.4KB, but this will only increase over time.

Risks

An additional HTTP request will have to be made to retrieve the YUI Configuration. However, this is largely mitigated by the presence of adequate headers to encourage browser caching.

Backwards compatibility

There should be no risks with regards backwards compatibilty.

Changes required

Addition of either:

  • a new file to serve the configuration - e.g. lib/yuilib/yui_config.php - this must take the $jsrev as part of the URL and should contain an additional parameter to allow us to add further configurations served from the same file.
  • an additional '$version' to /theme/yui_combo.php to achieve the same goal - e.g. theme/yui_combo.php/config/1234234212/yui


Move all YUI modules into the Y.Moodle namespace (from M)

Priority: High

Target release: 2.6

Description

At present, our YUI modules have historically been on the global M variable. The intention here is to move them to be under Y.Moodle.

Rationale

One of the great features of YUI is it's ability to sandbox a module into a reliable and reusable piece of code. Without this, it's possible for one instantiation to modify the module such that a future instantiation of the same module is not reliable or repeatable.

One of the ways that it achieves this is to use a functionally scoped Y object set up by the YUI().use() statement. All of the modules specified in the use are loaded afresh (without re-fetching). The module definition is such that it will add itself to the Y object making it available.

In order to successfully sandbox Moodle YUI modules, these must also existing in that Y namespace.

Risks

Some modules may already rely upon the broken sandboxing to ensure that they can't be called multiple times. These will need to be identified and addresses on a per-case basis.

Backwards Compatibility

Achieved by pointing the old namespace at the new one.

Convert Y.use() to YUI().use()

Priority: High

Target release: 2.6

Description

We currently load YUI modules in a single structure, which then *adds* modules to it's existing namespaces thereby preventing complete sandboxing:

  YUI().use('node', function(Y) {
    Y.use('moodle-core-example', function() {
      M.core.example.init();
    });
  });

This should be changed to:

  YUI().use('moodle-core-example', function(Y) {
    // Initially:
    M.core.example.init();
    // With the changes above:
    Y.Moodle.core.example.init();
  });

Convert remaining modules to use Shifter - MDL-38284

Priority: High This is relatively high priority. It would be great to be able to have all YUI modules in a consistent shape to make it easier for new users to developer YUI modules for Moodle.

Introduce JS Unit Tests + Code coverage using istanbul

Track down all uses of YUI2 in Moodle

  • plan rewrites of them
  • lib/form/yui/dateselector/dateselector.js
  • questionbank chooser

Look at rewrites for

YUIdoc Documentation

  • Document common modules:
    • notification
    • tooltip
    • chooserdialogue
  • Document all other modules

Wiki documentation

  • Shifter
  • Modules
  • JQuery
  • FAQ
  • Getting Started
    • Environment
  • Peer Review guidelines

Other

Key areas I'm currently working on

Some of my past project work