User:Andrew Nicols: Difference between revisions
(Add some tracker issues where relevant) |
(Add notes on more work) |
||
Line 2: | Line 2: | ||
== My thoughts on the JavaScript Roadmap for 2.6 and beyond == | == 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: | |||
<code> | |||
YUI.use('node', function(Y) { | |||
Y.use('moodle-core-example', function() { | |||
M.core.example.init(); | |||
}); | |||
}); | |||
</code> | |||
This should be changed to: | |||
<code> | |||
YUI().use('moodle-core-example', function(Y) { | |||
M.core.example.init(); | |||
}); | |||
</code> | |||
=== Convert remaining modules to use Shifter - MDL-38284=== | === 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. | 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. | ||
Line 33: | Line 81: | ||
** Environment | ** Environment | ||
* Peer Review guidelines | * Peer Review guidelines | ||
= Other = | = Other = |
Revision as of 23:26, 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) {
M.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
- Creation of a course tagging infrastructure (https://docs.moodle.org/dev/Course_Tags)
Some of my past project work
- Javascript Module Chooser showing user help (http://tracker.moodle.org/browse/MDL-30617)
- Rewrite of course and block Javascript (http://tracker.moodle.org/browse/MDL-31052)