Moodle

migrate old non-widget YUI2 code to new YUI3

Details

  • Type: Sub-task Sub-task
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 2.0
  • Fix Version/s: 2.0
  • Component/s: General
  • Labels:
    None
  • Affected Branches:
    MOODLE_20_STABLE
  • Fixed Branches:
    MOODLE_20_STABLE

Description

1/ At present we are including following yui2 libs on each page: dom, connection, container
2/ javascript-static.js is using YUI2 functions
3/ ajaxcourse, blocs, etc is using DOM, D&D...
4/ just search for "YAHOO."

There are only a few exceptions that use things not available in YUI3 yet (UI widgets), I think all DOM, D&D, ajax calls, JSON, etc. could be converted to YUI3 relatively easily before the 2.0beta. But not really sure, because I did not try the migration yet. Could you please try to choose just one selfcontained area and test the conversion YUI2->YUI3 there and estimate time/effort needed? thanks a lot.

Issue Links

This issue will be resolved by:
MDL-21170 Migrating to YUI3, filepicker, filemanager, comment and form Major Closed
This issue is duplicated by:
MDL-21422 convert YUI2 to YUI3 Minor Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Petr Škoda (skodak) added a comment -

sending example how to use YUI2 from YUI3 code, please note it is enough to use "Y.user(yui2-calendar)" where the "yui2-" is a prefix for current version of YUI2 modules and "calendar" is the standard name of YUI2 module, all dependencies are loaded automatically on the fly.

Show
Petr Škoda (skodak) added a comment - sending example how to use YUI2 from YUI3 code, please note it is enough to use "Y.user(yui2-calendar)" where the "yui2-" is a prefix for current version of YUI2 modules and "calendar" is the standard name of YUI2 module, all dependencies are loaded automatically on the fly.
Hide
Permalink
Dongsheng Cai added a comment -

Petr, about Y.form issue, I just realize we are talking about different issue there, you are talking about the global namespace, I am talking about yui3 module.
For new file picker and Y.form, they work exactly like a node,event, io, the yui3 modules automatically attached to global Y, or YUI() instances.

take checkall() function for example:

function checkall(name) {
Y.use('form', function() {
var form = new Y.form({});
form.checkall(name);
});
}

when I call Y.use('form'), YUI3 automatically added form module to YUI modue list, we can also write it in this way:

function checkall(name) {
Y.use('form', function(M) {
var form = new M.form({});
form.checkall(name);
});
}

but, this M here not the global one.

Show
Dongsheng Cai added a comment - Petr, about Y.form issue, I just realize we are talking about different issue there, you are talking about the global namespace, I am talking about yui3 module. For new file picker and Y.form, they work exactly like a node,event, io, the yui3 modules automatically attached to global Y, or YUI() instances. take checkall() function for example: function checkall(name) { Y.use('form', function() { var form = new Y.form({}); form.checkall(name); }); } when I call Y.use('form'), YUI3 automatically added form module to YUI modue list, we can also write it in this way: function checkall(name) { Y.use('form', function(M) { var form = new M.form({}); form.checkall(name); }); } but, this M here not the global one.
Hide
Permalink
Petr Škoda (skodak) added a comment -

My point is to NOT use the "YUI.add('filepicker' because it makes the filepicker the integral part of YUI, this looks designed for widgets extending YUI library, but it might not be optimal for something as complex as moodle. We would have to add tons of stuff in there and it might get cluttered pretty quickly, also we never know they might add filepicker element into YUI4, right? So instead I proposed (credit goes to Sam for his previous work) to create a new object "M" in javascript static and then in filepicker.js woudl add itself into M:

// /lib/javascript-static.js
if (typeof M == "undefined" || !M) {
    var M = {};
}
// filepicker.js
if (typeof M.filepicker == "undefined" || !M.filepicker) {
    M.filepicker = function()  {
        // here go the file picker methods and also the options and configuration
        // it would have access to Y of course
    }
}

It would be just some EXTERNAL module (like YUI2 modules) loaded through Y.use('filepicker'), then you would access all filepicker stuff through global M.filepicker.xxxx(). Scripts loaded through $PAGE->js() would register in global M too.

Somebody might ask why should we mess with Y.use(), because it handles dependancies and loading on demand - some JS scripts get loaded only when you click some button, or hover mouse over something, or when some element is present in page. Real world example is editor switching on the fly - we add module information into yui3loader for all available editors, but load JS only for those actually needed on page, then we can load others when user clicks button to switch to the other editor.

Show
Petr Škoda (skodak) added a comment - My point is to NOT use the "YUI.add('filepicker' because it makes the filepicker the integral part of YUI, this looks designed for widgets extending YUI library, but it might not be optimal for something as complex as moodle. We would have to add tons of stuff in there and it might get cluttered pretty quickly, also we never know they might add filepicker element into YUI4, right? So instead I proposed (credit goes to Sam for his previous work) to create a new object "M" in javascript static and then in filepicker.js woudl add itself into M: 
// /lib/javascript-static.js
if (typeof M == "undefined" || !M) {
    var M = {};
}
// filepicker.js
if (typeof M.filepicker == "undefined" || !M.filepicker) {
    M.filepicker = function()  {
        // here go the file picker methods and also the options and configuration
        // it would have access to Y of course
    }
}
It would be just some EXTERNAL module (like YUI2 modules) loaded through Y.use('filepicker'), then you would access all filepicker stuff through global M.filepicker.xxxx(). Scripts loaded through $PAGE->js() would register in global M too. Somebody might ask why should we mess with Y.use(), because it handles dependancies and loading on demand - some JS scripts get loaded only when you click some button, or hover mouse over something, or when some element is present in page. Real world example is editor switching on the fly - we add module information into yui3loader for all available editors, but load JS only for those actually needed on page, then we can load others when user clicks button to switch to the other editor.
Hide
Permalink
Dongsheng Cai added a comment -

filepicker is a widget, it created from Javascript without any html, I made it rather separated from moodle, it only need moodle_cfg and an option varible, I cannot see the potential disadvantages to use modules.

Actaully, to use module is a recommended way to create YUI3 addons, please take a look at http://yuilibrary.com/gallery/ and http://yuilibrary.com/gallery/show/form.

for form, comments, filemanager, I would like to use M namespace, because they are connected to moodle code tightly, without moodle side code, they won't work.

Show
Dongsheng Cai added a comment - filepicker is a widget, it created from Javascript without any html, I made it rather separated from moodle, it only need moodle_cfg and an option varible, I cannot see the potential disadvantages to use modules. Actaully, to use module is a recommended way to create YUI3 addons, please take a look at http://yuilibrary.com/gallery/ and http://yuilibrary.com/gallery/show/form. for form, comments, filemanager, I would like to use M namespace, because they are connected to moodle code tightly, without moodle side code, they won't work.
Hide
Permalink
Petr Škoda (skodak) added a comment -

hmm, filepicker seems to be connected to the moodle side tightly too:

  • it works with the underlaying File API concept
  • it uses moodle configuration (hopefully to be moved under M)
  • it uses information from the form - I never liked the file picker centric JS code there, it should be handled 100% by forms lib and should be neutral because other parts of I (like the editors) need it too, not just the Filepicker (talking about draftitemids, file size limits, etc. which are specified in each form element separately)
  • it heavily connects through AJAX to several moodle scripts
  • uses repository plugins (those would have to live in Y too)
  • uses our language strings

Filepicker will not work without the moodle at all. If we want to add modules to YUI we should use some prefixes, sorry Y.filepicker alone is problematic for me, it would have to be Y.moodle-filepicker, but then it would have to use the global M anyway which is not recommended. So we would end up putting everything into Y. I would personally like to separate the M a bit more from the Y. M should be hopefully able to use later versions of YUI. Or maybe we could ship multiple versions of YUI and use versioning to solve some upgrade problems.

Show
Petr Škoda (skodak) added a comment - hmm, filepicker seems to be connected to the moodle side tightly too:
  • it works with the underlaying File API concept
  • it uses moodle configuration (hopefully to be moved under M)
  • it uses information from the form - I never liked the file picker centric JS code there, it should be handled 100% by forms lib and should be neutral because other parts of I (like the editors) need it too, not just the Filepicker (talking about draftitemids, file size limits, etc. which are specified in each form element separately)
  • it heavily connects through AJAX to several moodle scripts
  • uses repository plugins (those would have to live in Y too)
  • uses our language strings
Filepicker will not work without the moodle at all. If we want to add modules to YUI we should use some prefixes, sorry Y.filepicker alone is problematic for me, it would have to be Y.moodle-filepicker, but then it would have to use the global M anyway which is not recommended. So we would end up putting everything into Y. I would personally like to separate the M a bit more from the Y. M should be hopefully able to use later versions of YUI. Or maybe we could ship multiple versions of YUI and use versioning to solve some upgrade problems.
Hide
Permalink
Dongsheng Cai added a comment - - edited

it uses information from the form - I never liked the file picker centric JS code there, it should be handled 100% by forms lib and should be neutral because other parts of I (like the editors) need it too, not just the Filepicker (talking about draftitemids, file size limits, etc. which are specified in each form element separately)

Petr, can you explain this a bit, I don't understand, there is no filepicker core code in moodle form, just callback functions and js options.

Show
Dongsheng Cai added a comment - - edited
it uses information from the form - I never liked the file picker centric JS code there, it should be handled 100% by forms lib and should be neutral because other parts of I (like the editors) need it too, not just the Filepicker (talking about draftitemids, file size limits, etc. which are specified in each form element separately)
Petr, can you explain this a bit, I don't understand, there is no filepicker core code in moodle form, just callback functions and js options.

People

Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Moodle. Try JIRA - bug tracking software for your team.