Note:

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

User:Andrew Nicols: Difference between revisions

From MoodleDocs
(Add notes on more work)
(Correct code examples)
Line 35: Line 35:
We currently load YUI modules in a single structure, which then *adds* modules to it's existing namespaces thereby preventing complete sandboxing:
We currently load YUI modules in a single structure, which then *adds* modules to it's existing namespaces thereby preventing complete sandboxing:
<code>
<code>
   YUI.use('node', function(Y) {
   YUI().use('node', function(Y) {
     Y.use('moodle-core-example', function() {
     Y.use('moodle-core-example', function() {
       M.core.example.init();
       M.core.example.init();
Line 45: Line 45:
<code>
<code>
   YUI().use('moodle-core-example', function(Y) {
   YUI().use('moodle-core-example', function(Y) {
    // Initially:
     M.core.example.init();
     M.core.example.init();
    // With the changes above:
    Y.Moodle.core.example.init();
   });
   });
</code>
</code>

Revision as of 23:28, 30 April 2013

I am the component maintainer for AJAX and Javascript.

My thoughts on the JavaScript Roadmap for 2.6 and beyond

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

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