User:Andrew Nicols
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
- 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)