Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.9.2, 2.4.3
    • Fix Version/s: 2.5
    • Component/s: AJAX and JavaScript
    • Labels:
    • Testing Instructions:
      Hide

      (Testing difficulty = hard)

      developer and theme designer required:
      1/ see the linked docs page
      2/ add jquery to theme
      3/ add jquery to module
      4/ add jquery to block
      5/ try to override jquery UI css from theme

      Show
      (Testing difficulty = hard) developer and theme designer required: 1/ see the linked docs page 2/ add jquery to theme 3/ add jquery to module 4/ add jquery to block 5/ try to override jquery UI css from theme
    • Affected Branches:
      MOODLE_19_STABLE, MOODLE_24_STABLE
    • Fixed Branches:
      MOODLE_25_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      w13_MDL-15727_m25_jquery
    • Documentation link:
    • Rank:
      12618

      Description

      YUI3 is Moodle's main Javascript library. It has come a long way from the early days, is well documented and quite capable.

      However, jQuery has emerged as the defacto library for use by developers around the web, and a lot more people have experience with it.

      To make it easier for people to write Moodle plugins that:

      • allow them to use their existing skills and save time
      • don't conflict with other plugins
      • can address specific versions of Moodle safely

      we should integrate jQuery in Moodle core in a standard way for those authors to use alongside YUI3.

        Issue Links

          Activity

          Hide
          Nicolas Connault added a comment -

          According to wikipedia contributors, there are hundreds of AJAX frameworks available. YUI may not be among the 3 most popular, but it is among the 4 most popular, and certainly not among the "worst" libraries out there.

          Additionally, including a second framework would introduce confusion in the codebase, with people able to use both in the same code. Javascript being as forgiving as it is, we really must avoid this type of problem, and keep things consistent.

          Show
          Nicolas Connault added a comment - According to wikipedia contributors, there are hundreds of AJAX frameworks available. YUI may not be among the 3 most popular, but it is among the 4 most popular, and certainly not among the "worst" libraries out there. Additionally, including a second framework would introduce confusion in the codebase, with people able to use both in the same code. Javascript being as forgiving as it is, we really must avoid this type of problem, and keep things consistent.
          Hide
          Frank Ralf added a comment -

          Following the discussion in http://moodle.org/mod/forum/discuss.php?d=106312 (Use of JavaScript in Moodle) I would like to reopen this issue.

          http://moodle.org/mod/forum/discuss.php?d=106312&parent=469547 (by Urs Hunkler) provides some very good arguments in favour of jQuery (and some against YUI).

          Kind regards,
          Frank

          Show
          Frank Ralf added a comment - Following the discussion in http://moodle.org/mod/forum/discuss.php?d=106312 (Use of JavaScript in Moodle) I would like to reopen this issue. http://moodle.org/mod/forum/discuss.php?d=106312&parent=469547 (by Urs Hunkler) provides some very good arguments in favour of jQuery (and some against YUI). Kind regards, Frank
          Hide
          Jamie Robe added a comment -

          I agree with Frank, as well as Urs great post in the forums. jquery has meny benefits to offer. Having used it on other projects, I would prefer to have it available in moodle. From the standpoint of tryting to get more people to be empowered with ajax or ajax-like capabilities, jquery is rated by many as the best out there. There are so many great books on it too. I will keep watching this topic, even though it is "resolved".
          Thanks,
          Jamie

          Show
          Jamie Robe added a comment - I agree with Frank, as well as Urs great post in the forums. jquery has meny benefits to offer. Having used it on other projects, I would prefer to have it available in moodle. From the standpoint of tryting to get more people to be empowered with ajax or ajax-like capabilities, jquery is rated by many as the best out there. There are so many great books on it too. I will keep watching this topic, even though it is "resolved". Thanks, Jamie
          Hide
          Tim Hunt added a comment -

          Urs made a great forum post, I agree, but while it makes many good points, none of them are about jQuery vs YUI. Nor does it seriously propose includeing jQuery in Moodle. Please do not mis-represent.

          Show
          Tim Hunt added a comment - Urs made a great forum post, I agree, but while it makes many good points, none of them are about jQuery vs YUI. Nor does it seriously propose includeing jQuery in Moodle. Please do not mis-represent.
          Hide
          Frank Ralf added a comment -

          http://docs.moodle.org/en/User:Frank_Ralf/JavaScript1 shows a concrete example how a simple problem is solved using plain JavaScript, YUI and jQuery (which IMHO demonstrates that jQuery is indeed a leaner and more versatile framework, but it's no problem to use jQuery even without "official" support from Moodle).

          Frank

          Show
          Frank Ralf added a comment - http://docs.moodle.org/en/User:Frank_Ralf/JavaScript1 shows a concrete example how a simple problem is solved using plain JavaScript, YUI and jQuery (which IMHO demonstrates that jQuery is indeed a leaner and more versatile framework, but it's no problem to use jQuery even without "official" support from Moodle). Frank
          Hide
          Jonathan Cartland added a comment -

          More familiar with Drupal than Moodle, I've done a brief search of the documentation for hints about preferred methods of including javascript libraries. I'm sure that YUI has many virtues, but it's certainly not the only or best choice for everything.

          Finally found some information, but not until after reading that, "The official JavaScript library for Moodle is YUI. That may not be your favourite, but it's the one that was chosen after careful research, so live with it." (Development:JavaScript_guidelines)

          Seriously, this attitude is acceptable? I'm sure there's more to the story, but it seems to violate so many core values of the open source community. It feels bad, and I really want to like Moodle.

          Show
          Jonathan Cartland added a comment - More familiar with Drupal than Moodle, I've done a brief search of the documentation for hints about preferred methods of including javascript libraries. I'm sure that YUI has many virtues, but it's certainly not the only or best choice for everything. Finally found some information, but not until after reading that, "The official JavaScript library for Moodle is YUI. That may not be your favourite, but it's the one that was chosen after careful research, so live with it." (Development:JavaScript_guidelines) Seriously, this attitude is acceptable? I'm sure there's more to the story, but it seems to violate so many core values of the open source community. It feels bad, and I really want to like Moodle.
          Hide
          John Syrinek added a comment -

          I know this issue has been closed, but I'm sure there's a lot of developers out there that end up here in their search for using jQuery correctly with Moodle. In my opinion, including jQuery with a block, theme, plugin, etc. that uses it is bad design – this can lead to multiple copies of jQuery being included from multiple sources. This can lead to a lot of conflict.

          To solve this, I created a simple local plugin that's only slightly hackish (see version.php): https://github.com/johntron/moodle-jquery-plugin

          I wasn't aware of any output renderers that could be easily overridden, nor did I find any way to use a callback for content to be included in the head. Since I didn't know of any other way of doing this outside of patching core, I had to inject the jQuery dependency in the plugin's version.php file. If anyone has a better idea, I'm all ears.

          Show
          John Syrinek added a comment - I know this issue has been closed, but I'm sure there's a lot of developers out there that end up here in their search for using jQuery correctly with Moodle. In my opinion, including jQuery with a block, theme, plugin, etc. that uses it is bad design – this can lead to multiple copies of jQuery being included from multiple sources. This can lead to a lot of conflict. To solve this, I created a simple local plugin that's only slightly hackish (see version.php): https://github.com/johntron/moodle-jquery-plugin I wasn't aware of any output renderers that could be easily overridden, nor did I find any way to use a callback for content to be included in the head. Since I didn't know of any other way of doing this outside of patching core, I had to inject the jQuery dependency in the plugin's version.php file. If anyone has a better idea, I'm all ears.
          Hide
          Martin Dougiamas added a comment -

          Following recent discussions at the hackfest in Dublin, this is being re-opened.

          We will now add jQuery into the core libraries of Moodle 2.5 at least (with backports to previous versions still to be discussed).

          The policy we've decided on is:

          • Moodle will continue using YUI3 as our primary way of writing JS in Moodle.
          • jQuery code will not be accepted into core at any time, and will be removed from the one place we have it (in the mobile theme).
          • The jQuery library is provided solely for the convenience of Moodle add-on authors who are not able to use YUI3 for some reason.
          • Moodle major releases will be updated with the latest jQuery version at that time and this will be retained throughout the life of that stable branch.
          • Any plugin that uses jQuery must use our YUI loader to initialise it.
          • If you want a plugin using jQuery to be considered for core, you'll need to rewrite the JS using YUI3 http://www.jsrosettastone.com/
          Show
          Martin Dougiamas added a comment - Following recent discussions at the hackfest in Dublin, this is being re-opened. We will now add jQuery into the core libraries of Moodle 2.5 at least (with backports to previous versions still to be discussed). The policy we've decided on is: Moodle will continue using YUI3 as our primary way of writing JS in Moodle. jQuery code will not be accepted into core at any time, and will be removed from the one place we have it (in the mobile theme). The jQuery library is provided solely for the convenience of Moodle add-on authors who are not able to use YUI3 for some reason. Moodle major releases will be updated with the latest jQuery version at that time and this will be retained throughout the life of that stable branch. Any plugin that uses jQuery must use our YUI loader to initialise it. If you want a plugin using jQuery to be considered for core, you'll need to rewrite the JS using YUI3 http://www.jsrosettastone.com/
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Fatty Moodle. I still don't get why this cannot be an add-on, and anybody using it declare the needed dependency.

          Show
          Eloy Lafuente (stronk7) added a comment - Fatty Moodle. I still don't get why this cannot be an add-on, and anybody using it declare the needed dependency.
          Hide
          Justin Filip added a comment -

          There is an existing moodle-local_jquery which sort of does this but not exactly – https://github.com/bumoodle/moodle-local_jquery

          We (Remote-Learner) created our own to contain both the minified and uncompressed versions and set the plugin version integer to be the release date of that version of jQuery so that other plugins can require a minimum jQuery version.

          https://github.com/remotelearner/moodle-local_rljquery/commits/MOODLE_24_STABLE

          The idea of doing it that way came out of a discussion with David Mudrak on the beach in Bunker Bay during Hacktoberfest. =)

          Show
          Justin Filip added a comment - There is an existing moodle-local_jquery which sort of does this but not exactly – https://github.com/bumoodle/moodle-local_jquery We (Remote-Learner) created our own to contain both the minified and uncompressed versions and set the plugin version integer to be the release date of that version of jQuery so that other plugins can require a minimum jQuery version. https://github.com/remotelearner/moodle-local_rljquery/commits/MOODLE_24_STABLE The idea of doing it that way came out of a discussion with David Mudrak on the beach in Bunker Bay during Hacktoberfest. =)
          Hide
          David Mudrak added a comment -

          Thanks for the info Justin. I guess the obvious question is on the table - does such solution work for you well?

          Show
          David Mudrak added a comment - Thanks for the info Justin. I guess the obvious question is on the table - does such solution work for you well?
          Hide
          Justin Filip added a comment -

          Yes, it works fine for our needs. It was trivial effort to get it setup with the multiple commits for the various jQuery versions in the 22, 23 and 24 branches.

          Show
          Justin Filip added a comment - Yes, it works fine for our needs. It was trivial effort to get it setup with the multiple commits for the various jQuery versions in the 22, 23 and 24 branches.
          Hide
          Martin Dougiamas added a comment - - edited

          For the simple case this is fine and preferable, but there are examples where a plugin will depend on different versions of such a local jquery plugin depending on the version of Moodle. Then there maybe multiple blocks, say, wanting multiple versions of jquery loaded at once, which is going to cause huge problems (some at the IE moot said they were already having such problems).

          For this, plus the general case where there are going to be a lot of random local plugins (ie not on the plugins database and perhaps not well written) around using jquery, I think it makes sense to enforce and publicise a certain jquery version per stable branch of Moodle.

          Anyone wanting to use jquery has to use the YUI loader call to load it and then use the version we give them (which is guaranteed to be there and to be a known version).

          It's actually restricting people who insist on developing with jQuery to REDUCE bloat and effort for Moodle admins in the long run.

          Already it's looking like Remote Learner would be having a /local/rljquery plugin plus an /local/jquery plugin to support different versions and requirements. It gets messy.

          There's no reason why a plugin can't still exist and be used if people want to, but if we are going to officially support jQuery in any way then I think this 1-1 built-in relationship with Moodle versions makes a lot of sense.

          Show
          Martin Dougiamas added a comment - - edited For the simple case this is fine and preferable, but there are examples where a plugin will depend on different versions of such a local jquery plugin depending on the version of Moodle. Then there maybe multiple blocks, say, wanting multiple versions of jquery loaded at once, which is going to cause huge problems (some at the IE moot said they were already having such problems). For this, plus the general case where there are going to be a lot of random local plugins (ie not on the plugins database and perhaps not well written) around using jquery, I think it makes sense to enforce and publicise a certain jquery version per stable branch of Moodle. Anyone wanting to use jquery has to use the YUI loader call to load it and then use the version we give them (which is guaranteed to be there and to be a known version). It's actually restricting people who insist on developing with jQuery to REDUCE bloat and effort for Moodle admins in the long run. Already it's looking like Remote Learner would be having a /local/rljquery plugin plus an /local/jquery plugin to support different versions and requirements. It gets messy. There's no reason why a plugin can't still exist and be used if people want to, but if we are going to officially support jQuery in any way then I think this 1-1 built-in relationship with Moodle versions makes a lot of sense.
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          I still don't get the difference, sorry:

          1) The "multiple jquery" problem will be the same, both if installed as library or add-on.

          2) An add-on version can be published for each release, exactly the same than the library.

          3) YUI will load jquery, any problem if done via add-on ?

          4) The 1-1 thingy, I don't get it. IMO 2) above provides that.

          And then, the benefits of having it like an add-on:

          B1) People not needing it won't have it. Say security problems, size, whatever. Why add something if it's not being used.

          B2) Any plugin requiring jquery can declare it via standard plugin dependencies, so admins will be informed about that and will decide if it's worth intalling jquery or no.

          B3) No jquery-dependent code will land into core ever (by mistake). Simply because it's not there and won't work.

          B4) We can know the number of uses of the jquery add-on from the updates API.

          B5) It allows to produce minor (fixup / security) upgrades independent of Moodle core. That independence also means "more options" so people using, say, 2.6 can remain sticky to the 2.5 local_jquery plugin if their add-ons haven't been upgraded yet.

          B6) The same solution can be applied to any other library out there (mootools, prototype, whatever). In fact perhaps it wouldn't be crazy to create a new lib_xxx plugin type for this.

          Surely there are drawbacks, but I still haven't find any. Sure I'm missing something obvious, so apologies, but I'm unable to find what.

          And apologies too if I've sounded too rude when commenting in other places this (current proposal) was a bad decision. I was not pointing to any person but to the solution itself. And always under my POV. And it does not sound rude at all to say that in Spanish, so sorry^3.

          But I still don't get it. Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - - edited I still don't get the difference, sorry: 1) The "multiple jquery" problem will be the same, both if installed as library or add-on. 2) An add-on version can be published for each release, exactly the same than the library. 3) YUI will load jquery, any problem if done via add-on ? 4) The 1-1 thingy, I don't get it. IMO 2) above provides that. And then, the benefits of having it like an add-on: B1) People not needing it won't have it. Say security problems, size, whatever. Why add something if it's not being used. B2) Any plugin requiring jquery can declare it via standard plugin dependencies, so admins will be informed about that and will decide if it's worth intalling jquery or no. B3) No jquery-dependent code will land into core ever (by mistake). Simply because it's not there and won't work. B4) We can know the number of uses of the jquery add-on from the updates API. B5) It allows to produce minor (fixup / security) upgrades independent of Moodle core. That independence also means "more options" so people using, say, 2.6 can remain sticky to the 2.5 local_jquery plugin if their add-ons haven't been upgraded yet. B6) The same solution can be applied to any other library out there (mootools, prototype, whatever). In fact perhaps it wouldn't be crazy to create a new lib_xxx plugin type for this. Surely there are drawbacks, but I still haven't find any. Sure I'm missing something obvious, so apologies, but I'm unable to find what. And apologies too if I've sounded too rude when commenting in other places this (current proposal) was a bad decision. I was not pointing to any person but to the solution itself. And always under my POV. And it does not sound rude at all to say that in Spanish, so sorry^3. But I still don't get it. Ciao
          Hide
          Tyler Bannister added a comment -

          Whether it's a local plugin (for the reasons Eloy cited) or built into core, it would probably be a good idea to use Google Hosted Libraries or one of it's alternatives*. Essentially, by using a content delivery network (CDN) hosted copy of jQuery, it becomes reasonably likely that the jQuery library has already been loaded into the browser's cache. If it's cached, we can entirely avoid downloading a new copy and if it's not, then we get the advantages of decreased latency and increase parrallelism.

          Of course, if we do implement support for CDN-hosted versions of jQuery, we should also implement a fallback solution to load the local copy in case the file isn't cached and the CDN is unavailable or blocked.

          • Technically, we could also add support for multiple CDNs and allow the admin to select which one, if any, to use.
          Show
          Tyler Bannister added a comment - Whether it's a local plugin (for the reasons Eloy cited) or built into core, it would probably be a good idea to use Google Hosted Libraries or one of it's alternatives *. Essentially, by using a content delivery network (CDN) hosted copy of jQuery, it becomes reasonably likely that the jQuery library has already been loaded into the browser's cache. If it's cached, we can entirely avoid downloading a new copy and if it's not, then we get the advantages of decreased latency and increase parrallelism. Of course, if we do implement support for CDN-hosted versions of jQuery, we should also implement a fallback solution to load the local copy in case the file isn't cached and the CDN is unavailable or blocked. Technically, we could also add support for multiple CDNs and allow the admin to select which one, if any, to use.
          Hide
          Gareth J Barnard added a comment -

          Hi,

          Following on from the YUI Loader concept, Andrew Nicols supplied me with some code to test for the MyMobile theme. Please see https://moodle.org/mod/forum/discuss.php?d=223182.

          It seems to me that anybody using jQuery could use:

          YUI().use('jquery', function(Y)

          { custom code }

          ); etc.

          However, this would mean jQuery js files in core if done that way. But as the only current practical use of jQuery in Moodle is the MyMobile theme and jQueryMobile versions require specific jQuery versions. Then best left within the theme only leaving core 99% pure YUI. And have this as the allowable mechanism for plugin developers. Thus providing users / admins with a clear choice that if their Moodle runs slow after installing the plugin (contrib / add-on) then it must be the plugin and they can complain to it's developer and revert back to vanilla Moodle.

          Even though CDN's are a good idea, for stability I would always use a local hosted copy in such a high availability system. And be sure it's the correct version of the file I tested against.

          These are just my thoughts and are not designed to be ammunition in a flame war

          Cheers,

          Gareth

          Show
          Gareth J Barnard added a comment - Hi, Following on from the YUI Loader concept, Andrew Nicols supplied me with some code to test for the MyMobile theme. Please see https://moodle.org/mod/forum/discuss.php?d=223182 . It seems to me that anybody using jQuery could use: YUI().use('jquery', function(Y) { custom code } ); etc. However, this would mean jQuery js files in core if done that way. But as the only current practical use of jQuery in Moodle is the MyMobile theme and jQueryMobile versions require specific jQuery versions. Then best left within the theme only leaving core 99% pure YUI. And have this as the allowable mechanism for plugin developers. Thus providing users / admins with a clear choice that if their Moodle runs slow after installing the plugin (contrib / add-on) then it must be the plugin and they can complain to it's developer and revert back to vanilla Moodle. Even though CDN's are a good idea, for stability I would always use a local hosted copy in such a high availability system. And be sure it's the correct version of the file I tested against. These are just my thoughts and are not designed to be ammunition in a flame war Cheers, Gareth
          Hide
          Andrew Nicols added a comment - - edited

          Eloy Lafuente (stronk7):
          1) the multiple jQuery plugin can be catered for by using the YUI Loader correctly The YUI Loader is awesome and allows us to completely sandbox jQuery so that it can't interfere with itself, or those around it. In theory, we can then deal with multiple versions of jquery all in one go - as if by magic.
          2) This should work too yes
          3) At present yes - there is a blocker to this. At the very least we should sort this out somehow. In order to use the YUI Loader, we need to add a group configuration to the YUI config. This is currently not possible. $PAGE->YUI_config is protected, and we have no functions to add or manage groups. If we could do this, then we could provide a way for an local plugin to provide their own library (e.g. Mootools, prototype, jquery, etc). Without this, the only way of realistically using the YUI Loader would be to include things in core.
          4) Not sure what the 1-1 thingy is??

          Tyler Bannister When including jQuery in core, we will require it be included using the YUI Loader which does allow us to specify it be included using a specific CDN. We already do this for YUI. There are certain situations when a CDN is not desirable. The following spring to mind, but I'm sure there are other reasons:

          • when your moodle is hosted on SSL; and
          • when on certain corporate/educational networks where this is blocked or counter to policy.

          I don't think that we will ever ship Moodle with the CDN enabled by default, but it will be provided as an option, and it will probably be possible (as with the existing YUI library) to specify a different CDN should you choose.

          I can see the benefits of allowing jQuery in core, but also the negatives that Eloy mentions. I think as part of the resolution to this issue we do need a way of specifying other JS libraries (not just jQuery) in the YUI loader configuration. This may change how we view the inclusion of jQuery and it's counterparts in core. For example, I don't know whether we should include extras like jquery-ui and jquery-mobile in core, but these may be considered in a local plugin - Martin Dougiamas may have specific views on this case. Additionally, a local plugin could be updated more frequently than a core plugin. On the other hand, if we're not including jquery in core then we're adding an additional barrier to third-party developers who refuse to switch to YUI3 and they may just ignore the local plugin and do their own thing.

          Thanks to Gareth for posting the discussion he raised earlier and suggesting a very nice way for allowing existing code to be very easily included using the YUI loader without changing the JS at all. I should point out that the YUI config he mentions actually came from Evan Goer's book 'The YUI Cookbook' (though I had an almost identical solution to his before I came across his version which solved an issue I was trying to fix ).

          Andrew

          Show
          Andrew Nicols added a comment - - edited Eloy Lafuente (stronk7) : 1) the multiple jQuery plugin can be catered for by using the YUI Loader correctly The YUI Loader is awesome and allows us to completely sandbox jQuery so that it can't interfere with itself, or those around it. In theory, we can then deal with multiple versions of jquery all in one go - as if by magic. 2) This should work too yes 3) At present yes - there is a blocker to this. At the very least we should sort this out somehow. In order to use the YUI Loader, we need to add a group configuration to the YUI config. This is currently not possible. $PAGE->YUI_config is protected, and we have no functions to add or manage groups. If we could do this, then we could provide a way for an local plugin to provide their own library (e.g. Mootools, prototype, jquery, etc). Without this, the only way of realistically using the YUI Loader would be to include things in core. 4) Not sure what the 1-1 thingy is?? Tyler Bannister When including jQuery in core, we will require it be included using the YUI Loader which does allow us to specify it be included using a specific CDN. We already do this for YUI. There are certain situations when a CDN is not desirable. The following spring to mind, but I'm sure there are other reasons: when your moodle is hosted on SSL; and when on certain corporate/educational networks where this is blocked or counter to policy. I don't think that we will ever ship Moodle with the CDN enabled by default, but it will be provided as an option, and it will probably be possible (as with the existing YUI library) to specify a different CDN should you choose. I can see the benefits of allowing jQuery in core, but also the negatives that Eloy mentions. I think as part of the resolution to this issue we do need a way of specifying other JS libraries (not just jQuery) in the YUI loader configuration. This may change how we view the inclusion of jQuery and it's counterparts in core. For example, I don't know whether we should include extras like jquery-ui and jquery-mobile in core, but these may be considered in a local plugin - Martin Dougiamas may have specific views on this case. Additionally, a local plugin could be updated more frequently than a core plugin. On the other hand, if we're not including jquery in core then we're adding an additional barrier to third-party developers who refuse to switch to YUI3 and they may just ignore the local plugin and do their own thing. Thanks to Gareth for posting the discussion he raised earlier and suggesting a very nice way for allowing existing code to be very easily included using the YUI loader without changing the JS at all. I should point out that the YUI config he mentions actually came from Evan Goer's book 'The YUI Cookbook' (though I had an almost identical solution to his before I came across his version which solved an issue I was trying to fix ). Andrew
          Hide
          Andrew Nicols added a comment -

          WRT my previous points, I'm not 100% sure how best we could handle different versions of jQuery. At present the YUI gallery can do this by using a gallery version config argument when instantiating the YUI loader:

          YUI({
            gallery: '2010.04.08-12-35'
          }).use('gallery-foo', function(Y) {
          });
          

          I think that we may be able to do something similar for jQuery, but it's not a priority IMHO.

          Show
          Andrew Nicols added a comment - WRT my previous points, I'm not 100% sure how best we could handle different versions of jQuery. At present the YUI gallery can do this by using a gallery version config argument when instantiating the YUI loader: YUI({ gallery: '2010.04.08-12-35' }).use('gallery-foo', function(Y) { }); I think that we may be able to do something similar for jQuery, but it's not a priority IMHO.
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          The most I think on this, the most I see it as a new type of plugin, say "lib_xxxx", where not only JS frameworks fit but virtually everything and then let developers to use them for their add-ons in a standardized way. Imagine xxx-pdf or zend-xxxx... anything.

          I don't think it's adding a new barrier to anybody but, instead, organizing the way people uses non-core libraries, avoiding dupes and keeping everything under the "M" (of modular). It's all about to document and allow quick install IMO.

          Each plugin could "declare" what it's offering, supports/entry points, standard versions and dependencies... and then core should be able to ask them (via supports or any callback or new specific API for lib_xxx components) and act based on that.

          Say the "lib_jquery" declares it's a JS lib, to be loaded by YUI, or another lib_xxxx declares it needs to be loaded/executed as part of early moodle warmup, or autoload features... the possibilities are endless.

          I know what I'm proposing is more complex than simply adding jquery to core, tweak YUI and done (in fact, disclaimer, my knowledge of yui/jquery/js is pretty limited) . But thinking in the long term... all I'd put the emphasis in organization, and doing it using a new plugin type give us all the current benefits of our plugin automatically while we advance expanding the API when new uses arrive.

          And that's all, I hope the just commented "draft" helps for something.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - - edited The most I think on this, the most I see it as a new type of plugin, say "lib_xxxx", where not only JS frameworks fit but virtually everything and then let developers to use them for their add-ons in a standardized way. Imagine xxx-pdf or zend-xxxx... anything. I don't think it's adding a new barrier to anybody but, instead, organizing the way people uses non-core libraries, avoiding dupes and keeping everything under the "M" (of modular). It's all about to document and allow quick install IMO. Each plugin could "declare" what it's offering, supports/entry points, standard versions and dependencies... and then core should be able to ask them (via supports or any callback or new specific API for lib_xxx components) and act based on that. Say the "lib_jquery" declares it's a JS lib, to be loaded by YUI, or another lib_xxxx declares it needs to be loaded/executed as part of early moodle warmup, or autoload features... the possibilities are endless. I know what I'm proposing is more complex than simply adding jquery to core, tweak YUI and done (in fact, disclaimer, my knowledge of yui/jquery/js is pretty limited) . But thinking in the long term... all I'd put the emphasis in organization, and doing it using a new plugin type give us all the current benefits of our plugin automatically while we advance expanding the API when new uses arrive. And that's all, I hope the just commented "draft" helps for something. Ciao
          Hide
          Anthony Borrow added a comment -

          I agree with Eloy - whether we create a lib plugin type (lib/addon) or have jquery as a local plugin, I would like to see something that creates a consistent way of pulling in external libraries for use inside Moodle in a consistent way. I would be curious how MoodleRooms (with the local_mr) which seems to function as a library for a variety of their other plugins. I've added Kris to get his thoughts. Peace - Anthony

          Show
          Anthony Borrow added a comment - I agree with Eloy - whether we create a lib plugin type (lib/addon) or have jquery as a local plugin, I would like to see something that creates a consistent way of pulling in external libraries for use inside Moodle in a consistent way. I would be curious how MoodleRooms (with the local_mr) which seems to function as a library for a variety of their other plugins. I've added Kris to get his thoughts. Peace - Anthony
          Hide
          Martin Dougiamas added a comment -

          Can someone please show me exactly how a YUI call to include jQuery would then load jQuery from some plugin? And then exactly how will jquery-based code be affected? Are there prefixes to add etc?

          The main reason I went for the core solution over library is not technical, it's practical. jQuery devs are using jQuery precisely because they don't want to learn the Moodle way to do things. They might just be coding up a quick fun block with a clock in it or something to use on their own site, and cutting and pasting code from a blog they read. We could say that they need to do A, B and C in their block to make anything work but I'd rather just say A. That's all I'm trying to do.

          I'd also like to announce for 2.5 that we have a supported solution for jQuery, which probably means no major refactoring. http://xkcd.com/974/ That's a political thing, because I want Moodle to be extending a hand to those fringe developers who hate/misunderstand YUI and are thus avoiding doing work on Moodle (in various local contexts, not talking about moodle.org/plugins).

          So whatever we decide, make it easy-to-use and quick.

          Show
          Martin Dougiamas added a comment - Can someone please show me exactly how a YUI call to include jQuery would then load jQuery from some plugin? And then exactly how will jquery-based code be affected? Are there prefixes to add etc? The main reason I went for the core solution over library is not technical, it's practical. jQuery devs are using jQuery precisely because they don't want to learn the Moodle way to do things. They might just be coding up a quick fun block with a clock in it or something to use on their own site, and cutting and pasting code from a blog they read. We could say that they need to do A, B and C in their block to make anything work but I'd rather just say A. That's all I'm trying to do. I'd also like to announce for 2.5 that we have a supported solution for jQuery, which probably means no major refactoring. http://xkcd.com/974/ That's a political thing, because I want Moodle to be extending a hand to those fringe developers who hate/misunderstand YUI and are thus avoiding doing work on Moodle (in various local contexts, not talking about moodle.org/plugins). So whatever we decide, make it easy-to-use and quick.
          Hide
          Martin Dougiamas added a comment -

          Specific to B5 in Eloy's post above, what happens if some blocks are upgraded and some aren't? Are we going to have one new plugin per version? lib/jquery25 /lib/jquery26 ?

          Show
          Martin Dougiamas added a comment - Specific to B5 in Eloy's post above, what happens if some blocks are upgraded and some aren't? Are we going to have one new plugin per version? lib/jquery25 /lib/jquery26 ?
          Hide
          Gareth J Barnard added a comment -

          Dear Martin Dougiamas,

          The YUI code loads jQuery within a .use() scope so for example with the MyMobile theme:

          YUI.applyConfig({
              groups: {
                  'jquery': {
                      async: false,
                      combine: true,
                      modules: {
                          'jquery': {
                              fullpath: M.cfg.wwwroot + '/theme/mymobile/javascript/jquery-1.7.1.min.js'
                          },
                          'jquery-mymobile-custom': {
                              fullpath: M.cfg.wwwroot + '/theme/mymobile/javascript/custom.js',
                              requires: ['jquery']
                          },
                          'jquery-mymobile': {
                              fullpath: M.cfg.wwwroot + '/theme/mymobile/javascript/jquery.mobile-1.1.1.js',
                              requires: ['jquery-mymobile-custom']
                          }
                      }
                  }
              }
          });
          YUI().use('jquery-mymobile', function(Y) { // Additional user jQuery code here, });
          

          Another example from the original code written by Andrew Nicols with what works and what does not can be found here: http://jsfiddle.net/andrewnicols/WaFDA/

          Therefore jQuery is only used within a specific scope.

          In reference of why dev's are using jQuery instead of the Moodle way of doing things might be two fold. Firstly because a certain element of functionality is not available in YUI such as jQueryMobile - I believe with a Google of this that there is talk of a YUI Mobile library - this is also my main reason at the moment. Secondly, transferable skills, developers who are paid will code to what the customer wants, but as contrib / add-on developers (perhaps all that are asking for jQuery) are performing the work for free then two possibilities. 1. They learnt jQuery for another paid project but do not use YUI or have time to learn it in their free time. 2. They perceive that learning YUI for such a worthy cause will not benefit their ability to seek paid work, therefore learning YUI in their free time is not CV friendly. I'm sure if YUI became a top requirement in recruitment agency advertising then I'm sure we would not even be having this debate. But from my perspective I see jQuery everywhere and hardly ever YUI. This is a hearts and minds exercise. YUI might be the BetaMax and jQuery the VHS of the JavaScript world in terms of technical implementation but it is what the clients want that is driving developers free time.

          These are just my thoughts on the issue and not based upon complete research of the area.

          Kind regards,

          Gareth

          Show
          Gareth J Barnard added a comment - Dear Martin Dougiamas , The YUI code loads jQuery within a .use() scope so for example with the MyMobile theme: YUI.applyConfig({ groups: { 'jquery': { async: false , combine: true , modules: { 'jquery': { fullpath: M.cfg.wwwroot + '/theme/mymobile/javascript/jquery-1.7.1.min.js' }, 'jquery-mymobile-custom': { fullpath: M.cfg.wwwroot + '/theme/mymobile/javascript/custom.js', requires: ['jquery'] }, 'jquery-mymobile': { fullpath: M.cfg.wwwroot + '/theme/mymobile/javascript/jquery.mobile-1.1.1.js', requires: ['jquery-mymobile-custom'] } } } } }); YUI().use('jquery-mymobile', function(Y) { // Additional user jQuery code here, }); Another example from the original code written by Andrew Nicols with what works and what does not can be found here: http://jsfiddle.net/andrewnicols/WaFDA/ Therefore jQuery is only used within a specific scope. In reference of why dev's are using jQuery instead of the Moodle way of doing things might be two fold. Firstly because a certain element of functionality is not available in YUI such as jQueryMobile - I believe with a Google of this that there is talk of a YUI Mobile library - this is also my main reason at the moment. Secondly, transferable skills, developers who are paid will code to what the customer wants, but as contrib / add-on developers (perhaps all that are asking for jQuery) are performing the work for free then two possibilities. 1. They learnt jQuery for another paid project but do not use YUI or have time to learn it in their free time. 2. They perceive that learning YUI for such a worthy cause will not benefit their ability to seek paid work, therefore learning YUI in their free time is not CV friendly. I'm sure if YUI became a top requirement in recruitment agency advertising then I'm sure we would not even be having this debate. But from my perspective I see jQuery everywhere and hardly ever YUI. This is a hearts and minds exercise. YUI might be the BetaMax and jQuery the VHS of the JavaScript world in terms of technical implementation but it is what the clients want that is driving developers free time. These are just my thoughts on the issue and not based upon complete research of the area. Kind regards, Gareth
          Hide
          Mark Nielsen added a comment -

          Since there is some discussion on how/where to install vendor dependencies, I'd just like to throw out there that Composer already does this for us. We can install from this repo: https://github.com/components/jquery

          In addition, there is Bower which is basically Composer for front end developers. It would use the same git repo that I linked above for Composer though.

          This could naturally lead to a lengthy debate on if we want to require that Moodle installs have to run these package managers to install these dependencies. More likely though, we would just commit the result to the Moodle repository.

          I also understand though that this isn't equivalent to a lib_xxx plugin idea as it wouldn't be plug and play, but I feel like what we are trying to do is include vendor code consistently and in a way we can update later with relative ease. Package managers would help us out there.

          Show
          Mark Nielsen added a comment - Since there is some discussion on how/where to install vendor dependencies, I'd just like to throw out there that Composer already does this for us. We can install from this repo: https://github.com/components/jquery In addition, there is Bower which is basically Composer for front end developers. It would use the same git repo that I linked above for Composer though. This could naturally lead to a lengthy debate on if we want to require that Moodle installs have to run these package managers to install these dependencies. More likely though, we would just commit the result to the Moodle repository. I also understand though that this isn't equivalent to a lib_xxx plugin idea as it wouldn't be plug and play, but I feel like what we are trying to do is include vendor code consistently and in a way we can update later with relative ease. Package managers would help us out there.
          Hide
          Gareth J Barnard added a comment -

          Dear Mark Nielsen,

          The problem with https://github.com/components/jquery is that it is jQuery 1.9.1 which is not supported on jQueryMobile 1.2.0. And even though jQueryMobile 1.3.0. does work with jQuery 1.9.1, there is a problem with the 'listview' widget, therefore I consider simple manageable small code maintainable control using Andrew's YUI solution is the best rather than chucking in a whole new load of baggage.

          Cheers,

          Gareth

          Show
          Gareth J Barnard added a comment - Dear Mark Nielsen , The problem with https://github.com/components/jquery is that it is jQuery 1.9.1 which is not supported on jQueryMobile 1.2.0. And even though jQueryMobile 1.3.0. does work with jQuery 1.9.1, there is a problem with the 'listview' widget, therefore I consider simple manageable small code maintainable control using Andrew's YUI solution is the best rather than chucking in a whole new load of baggage. Cheers, Gareth
          Hide
          Petr Škoda added a comment -

          Hmm, the problem here is that using of YUI loader requires extra knowledge and different coding style, I am afraid that people request standard jquery inclusion without YUI. It is sad that jQueryMobile does not support the latest jQuery version, is the 'listview' problem reported somewhere? Such as https://github.com/jquery/jquery-mobile/issues/search?q=listview Is there some workaround? I would prefer to include 1.9.1 instead of 1.8.3.

          Gereth: are you going to be around this week? I am looking for somebody willing to review my jquery patches...

          Show
          Petr Škoda added a comment - Hmm, the problem here is that using of YUI loader requires extra knowledge and different coding style, I am afraid that people request standard jquery inclusion without YUI. It is sad that jQueryMobile does not support the latest jQuery version, is the 'listview' problem reported somewhere? Such as https://github.com/jquery/jquery-mobile/issues/search?q=listview Is there some workaround? I would prefer to include 1.9.1 instead of 1.8.3. Gereth: are you going to be around this week? I am looking for somebody willing to review my jquery patches...
          Hide
          Petr Škoda added a comment - - edited

          "jQuery Mobile 1.3.1 within 2 weeks (https://jquery.org/updates/)", is it fixed there?

          Show
          Petr Škoda added a comment - - edited "jQuery Mobile 1.3.1 within 2 weeks ( https://jquery.org/updates/ )", is it fixed there?
          Hide
          Gareth J Barnard added a comment -

          Dear Petr Škoda,

          I'd be happy to review your patches. But given the decisions above and discussions over jQuery in core I am concerned that the time will be wasted.

          The YUI loader was created as a result of the decisions above as an 'essential' and to be honest does not require hardly any skill to use it. All you need to do is point the file paths in the right direction and if need be follow the dependency flow and adapt it if required - not rocket science.

          As for 'listview', I hope it is fixed in JQM 1.3.1 (I've not kept track of recent developments) and perhaps JQM 1.2.1 will support JQ 1.9.1.

          And even though JQM 1.2.0 does not officially support JQ 1.9.1 it will work with it when combined with jQuery Migrate 1.1.0 - I've tested this combination on a small scale.

          Cheers,

          Gareth

          Show
          Gareth J Barnard added a comment - Dear Petr Škoda , I'd be happy to review your patches. But given the decisions above and discussions over jQuery in core I am concerned that the time will be wasted. The YUI loader was created as a result of the decisions above as an 'essential' and to be honest does not require hardly any skill to use it. All you need to do is point the file paths in the right direction and if need be follow the dependency flow and adapt it if required - not rocket science. As for 'listview', I hope it is fixed in JQM 1.3.1 (I've not kept track of recent developments) and perhaps JQM 1.2.1 will support JQ 1.9.1. And even though JQM 1.2.0 does not officially support JQ 1.9.1 it will work with it when combined with jQuery Migrate 1.1.0 - I've tested this combination on a small scale. Cheers, Gareth
          Hide
          Petr Škoda added a comment -

          I disagree, the proper solution is to not use jQuery at all, I am afraid that adding it via YUI loader would only create new problems, for example it seems you can not mix global and sandboxed jQuery instance by default, there seem to be some workarounds but... In any case add-on devs will continue trying to load jQuery in global scope no matter what we do - those are the potential customers of my patch, jQuery will not be still allowed in core Moodle. Hopefully the bootstrap based themes will fully replace the mobile theme in 2.6 and we will not have to deal with this any more in core.

          What I would like to do is:
          1/ one version of jQuery
          2/ everything loaded in global JS scope - moodle plugins would use PAGE->requires->jquery()
          3/ jQueryUI and migrate plugins in core - moodle plugins would use PAGE->requires->jquery_plugin('ui') or PAGE->requires->jquery_plugin('migrate')
          4/ new hooks for PAGE init in themes and blocks
          5/ tons of warnings for developers trying to persuade them to use YUI instead

          Show
          Petr Škoda added a comment - I disagree, the proper solution is to not use jQuery at all, I am afraid that adding it via YUI loader would only create new problems, for example it seems you can not mix global and sandboxed jQuery instance by default, there seem to be some workarounds but... In any case add-on devs will continue trying to load jQuery in global scope no matter what we do - those are the potential customers of my patch, jQuery will not be still allowed in core Moodle. Hopefully the bootstrap based themes will fully replace the mobile theme in 2.6 and we will not have to deal with this any more in core. What I would like to do is: 1/ one version of jQuery 2/ everything loaded in global JS scope - moodle plugins would use PAGE->requires->jquery() 3/ jQueryUI and migrate plugins in core - moodle plugins would use PAGE->requires->jquery_plugin('ui') or PAGE->requires->jquery_plugin('migrate') 4/ new hooks for PAGE init in themes and blocks 5/ tons of warnings for developers trying to persuade them to use YUI instead
          Hide
          Gareth J Barnard added a comment -

          Dear Petr Škoda,

          To be honest, I'm not that bothered about how jQuery is loaded as long as I can use it in support of my add-ons. I have my own improved version of the MyMobile theme that works well with Collapsed Topics to provide a solution that users have been asking me for ages. It also incorporates MDL-31342 which I suspect will solve a lot of MyMobile's woes. I also have other trial code that employs the jQuery noConflict function to deal with conflicting versions that does not use YUI at all which I'm happy to share if asked.

          I don't know enough about Bootstrap and it's underlying JavaScript framework facilitators to comment.

          So, to support Moodle development and contribute to the community, I'm happy to review your code.

          Cheers,

          Gareth

          Show
          Gareth J Barnard added a comment - Dear Petr Škoda , To be honest, I'm not that bothered about how jQuery is loaded as long as I can use it in support of my add-ons. I have my own improved version of the MyMobile theme that works well with Collapsed Topics to provide a solution that users have been asking me for ages. It also incorporates MDL-31342 which I suspect will solve a lot of MyMobile's woes. I also have other trial code that employs the jQuery noConflict function to deal with conflicting versions that does not use YUI at all which I'm happy to share if asked. I don't know enough about Bootstrap and it's underlying JavaScript framework facilitators to comment. So, to support Moodle development and contribute to the community, I'm happy to review your code. Cheers, Gareth
          Hide
          Martin Dougiamas added a comment -

          Thanks a lot for your help, Gareth, really appreciated.

          Show
          Martin Dougiamas added a comment - Thanks a lot for your help, Gareth, really appreciated.
          Hide
          Amy Groshek added a comment -

          Petr Škoda Your concerns are legitimate, but as you say, it's very important we begin to standardize the inclusion of a known version of jQuery in versions of Moodle. We also have SimpleYUI available, for those who just want to do simple theme hacks. I like that there is also a plan for loading jQuery UI. I think that's important. jQuery users are capable of reading documentation just like YUI users (in fact, jQuery users are accustomed to comprehensive documentation, and this is part of the reason they grow frustrated with YUI). That digression to make the point that so long as we document very well how to do it the right way, we're in good standing to prevent and/or weed out collisions in the global namespace.

          I can also help with testing this. I can also help with writing the documentation. Let me know where assistance is needed.

          Show
          Amy Groshek added a comment - Petr Škoda Your concerns are legitimate, but as you say, it's very important we begin to standardize the inclusion of a known version of jQuery in versions of Moodle. We also have SimpleYUI available, for those who just want to do simple theme hacks. I like that there is also a plan for loading jQuery UI. I think that's important. jQuery users are capable of reading documentation just like YUI users (in fact, jQuery users are accustomed to comprehensive documentation, and this is part of the reason they grow frustrated with YUI). That digression to make the point that so long as we document very well how to do it the right way, we're in good standing to prevent and/or weed out collisions in the global namespace. I can also help with testing this. I can also help with writing the documentation. Let me know where assistance is needed.
          Hide
          Gareth J Barnard added a comment - - edited

          Dear Martin Dougiamas,

          A pleasure.

          Cheers,

          Gareth

          Show
          Gareth J Barnard added a comment - - edited Dear Martin Dougiamas , A pleasure. Cheers, Gareth
          Hide
          Petr Škoda added a comment -

          here is my work in progress, it should hopefully illustrate what I was talking about (there are still some rough edges, little testing and few docs):

          https://github.com/skodak/moodle/compare/43bd811...wip_MDL-15727_m25_jquery

          Usage in normal code, file /xx.php:

          
          <?php
          require('config.php');
          $PAGE->set_url('/xx.php');
          $PAGE->set_context(null);
          $PAGE->requires->jquery();
          $PAGE->requires->jquery_plugin('ui');
          $PAGE->requires->jquery_plugin('ui-css');
          echo $OUTPUT->header();
          ?>
          <div id="dialog" title="Basic dialog">
            <p>This is the default dialog which is useful for displaying information. The dialog window can be moved, resized and closed with the 'x' icon.</p>
          </div>
              <script>
                  $(function() {
                      $( "#dialog" ).dialog();
                  });
              </script>
          <?php
          echo $OUTPUT->footer();
          

          usage from theme lib.php file:

          <?php
          function theme_standard_page_init($page) {
              $page->requires->jquery();
              $page->requires->jquery_plugin('ui');
              $page->requires->jquery_plugin('ui-css');
          }
          
          Show
          Petr Škoda added a comment - here is my work in progress, it should hopefully illustrate what I was talking about (there are still some rough edges, little testing and few docs): https://github.com/skodak/moodle/compare/43bd811...wip_MDL-15727_m25_jquery Usage in normal code, file /xx.php: <?php require('config.php'); $PAGE->set_url('/xx.php'); $PAGE->set_context( null ); $PAGE->requires->jquery(); $PAGE->requires->jquery_plugin('ui'); $PAGE->requires->jquery_plugin('ui-css'); echo $OUTPUT->header(); ?> <div id= "dialog" title= "Basic dialog" > <p>This is the default dialog which is useful for displaying information. The dialog window can be moved, resized and closed with the 'x' icon.</p> </div> <script> $(function() { $( "#dialog" ).dialog(); }); </script> <?php echo $OUTPUT->footer(); usage from theme lib.php file: <?php function theme_standard_page_init($page) { $page->requires->jquery(); $page->requires->jquery_plugin('ui'); $page->requires->jquery_plugin('ui-css'); }
          Hide
          Petr Škoda added a comment -

          I have also added sample conversion of the mymobile theme to the new jquery infrastructure in the patch above...

          Show
          Petr Škoda added a comment - I have also added sample conversion of the mymobile theme to the new jquery infrastructure in the patch above...
          Hide
          Gareth J Barnard added a comment - - edited

          Dear Petr Škoda,

          Thank you for the information. A few observations:

          1. Can the page requires have a 'depends' to state order of loading in it's serving array?
          2. Can the 'file not found' 404 code state the file name not found.
          3. Will developers be able to override with their own version?
          4. Is this all done through themes?
          5. The MyMobile 'custom' script needs to be loaded between JQ and JQM - I cannot see this happening.
          6. The MyMobile JQM script is not pure from the source, it has a hack in it. So cannot be upgraded straight from 1.1.0 to 1.2.0 from source.
          7. The 'jmobile11' css code is actually a combination of the swatch and structure css files specifically generated to for JQM 1.1.0, therefore an upgrade to 1.2.0 has to be created. Which I think you may have spotted and done. However, you do not need the extra theme and structure css files.
          8. On reflection I consider that the changes to MyMobile you have done are outside of the remit of this tracker and should be a like for like in terms of JQ and JQM etc. As this causes conflicts with other issues that Mary Evans and I are working on to fix the theme. Therefore JQ and JQM should stay the same versions as far as this tracker is concerned. Unless it is there purely as an example and not to be placed in core (if only for a short while until it is removed for Bootstrap).
          9. Will you run the code through code checker?

          These are my initial thoughts and will keep reviewing, cheers,

          Gareth

          Show
          Gareth J Barnard added a comment - - edited Dear Petr Škoda , Thank you for the information. A few observations: 1. Can the page requires have a 'depends' to state order of loading in it's serving array? 2. Can the 'file not found' 404 code state the file name not found. 3. Will developers be able to override with their own version? 4. Is this all done through themes? 5. The MyMobile 'custom' script needs to be loaded between JQ and JQM - I cannot see this happening. 6. The MyMobile JQM script is not pure from the source, it has a hack in it. So cannot be upgraded straight from 1.1.0 to 1.2.0 from source. 7. The 'jmobile11' css code is actually a combination of the swatch and structure css files specifically generated to for JQM 1.1.0, therefore an upgrade to 1.2.0 has to be created. Which I think you may have spotted and done. However, you do not need the extra theme and structure css files. 8. On reflection I consider that the changes to MyMobile you have done are outside of the remit of this tracker and should be a like for like in terms of JQ and JQM etc. As this causes conflicts with other issues that Mary Evans and I are working on to fix the theme. Therefore JQ and JQM should stay the same versions as far as this tracker is concerned. Unless it is there purely as an example and not to be placed in core (if only for a short while until it is removed for Bootstrap). 9. Will you run the code through code checker? These are my initial thoughts and will keep reviewing, cheers, Gareth
          Hide
          Gareth J Barnard added a comment -

          Dear Mary Evans,

          Added you as a watcher as relates to themes.

          Cheers,

          Gareth

          Show
          Gareth J Barnard added a comment - Dear Mary Evans , Added you as a watcher as relates to themes. Cheers, Gareth
          Hide
          Gareth J Barnard added a comment - - edited

          To help with my point 5 above in the MyMobile example, the init code needs to be:

          function theme_mymobile_page_init($page) {
              $page->requires->jquery();
              $page->requires->jquery_plugin('migrate');
              $page->requires->jquery_plugin('custom', 'theme_mymobile');
              $page->requires->jquery_plugin('mobile', 'theme_mymobile');
              $page->requires->jquery_plugin('mobile-css', 'theme_mymobile');
          }
          

          Am I right in saying that the iteration order for an array in PHP is as added to the array? - for the 'depends' comment. Sorry, been doing Java this evening and switched context.

          Cheers,

          Gareth

          Show
          Gareth J Barnard added a comment - - edited To help with my point 5 above in the MyMobile example, the init code needs to be: function theme_mymobile_page_init($page) { $page->requires->jquery(); $page->requires->jquery_plugin('migrate'); $page->requires->jquery_plugin('custom', 'theme_mymobile'); $page->requires->jquery_plugin('mobile', 'theme_mymobile'); $page->requires->jquery_plugin('mobile-css', 'theme_mymobile'); } Am I right in saying that the iteration order for an array in PHP is as added to the array? - for the 'depends' comment. Sorry, been doing Java this evening and switched context. Cheers, Gareth
          Hide
          Andrew Nicols added a comment - - edited

          First commit:
          lib/outputrequirementslib.php jquery_override_plugin() - typo on oldplugin (oldpluign)
          lib/outputrequirementslib.php - phpdoc missing for new functions
          lib/outputrequirementslib.php - get_jquery_head_code - $name=>$unused should have spaces ($name => $unused)
          theme/jquery.php - NO_DEBUG_DISPLAY line is commented out at top

          It took me a little while to get my head around the plugin overrides - might be good to have some more docs and inline comment for those, particularly the cyclic test.

          Second commit:
          Probably don't need second comment in theme renderer - it confuses things.
          + // Hint: use get_required_javascript() method in blocks if you want to alter page from blocks.

          Otherwise I think this looks good and should really simplify jQuery usage

          Show
          Andrew Nicols added a comment - - edited First commit: lib/outputrequirementslib.php jquery_override_plugin() - typo on oldplugin (oldpluign) lib/outputrequirementslib.php - phpdoc missing for new functions lib/outputrequirementslib.php - get_jquery_head_code - $name=>$unused should have spaces ($name => $unused) theme/jquery.php - NO_DEBUG_DISPLAY line is commented out at top It took me a little while to get my head around the plugin overrides - might be good to have some more docs and inline comment for those, particularly the cyclic test. Second commit: Probably don't need second comment in theme renderer - it confuses things. + // Hint: use get_required_javascript() method in blocks if you want to alter page from blocks. Otherwise I think this looks good and should really simplify jQuery usage
          Hide
          Gareth J Barnard added a comment - - edited

          In 'jquery_override_plugin()' in 'outputrequirementslib.php', self cancelling typo on '$oldpluign'. EDIT: Spotted around the same time as Andrew and did not refresh tracker page!

          Show
          Gareth J Barnard added a comment - - edited In 'jquery_override_plugin()' in 'outputrequirementslib.php', self cancelling typo on '$oldpluign'. EDIT: Spotted around the same time as Andrew and did not refresh tracker page!
          Hide
          Gareth J Barnard added a comment - - edited

          I assume that the override plugin code is work in progress? Because of the fixed number loop, non-use of iterator value, no inclusion of overridden url and checking core lib not overridden.

          Show
          Gareth J Barnard added a comment - - edited I assume that the override plugin code is work in progress? Because of the fixed number loop, non-use of iterator value, no inclusion of overridden url and checking core lib not overridden.
          Hide
          Andrew Nicols added a comment -

          Hi Gareth,

          The iterator is not used but is used to restrict the cyclic test to a reasonable number. It's intended to check that the plugin overrides don't keep overriding themselves in such a way that it gets stuck in a loop when resolving them. The $name var is overwritten each time to this end. A hard codes number is used to make sure we don't get stuck in a loop here either. It may be better written as a do while loop though to allow it to exit earlier if a plugin is not overwritten but it's 1am and I may be mis thinking that bit.

          It may be desirable for a Moodle plugin to override core lib - why should we check that it isn't overridden?

          Show
          Andrew Nicols added a comment - Hi Gareth, The iterator is not used but is used to restrict the cyclic test to a reasonable number. It's intended to check that the plugin overrides don't keep overriding themselves in such a way that it gets stuck in a loop when resolving them. The $name var is overwritten each time to this end. A hard codes number is used to make sure we don't get stuck in a loop here either. It may be better written as a do while loop though to allow it to exit earlier if a plugin is not overwritten but it's 1am and I may be mis thinking that bit. It may be desirable for a Moodle plugin to override core lib - why should we check that it isn't overridden?
          Hide
          Gareth J Barnard added a comment -

          Dear Andrew Nicols,

          Thanks , I'm still trying to wrap my head around the $name part of the override code and understand that particular PHP syntax.

          The check that it's not is based upon the line in the 'jquery_plugin' method:

          if ($component !== 'core' and ($plugin === 'jquery' or $plugin === 'ui-css' or $plugin === 'migrate' or $plugin === 'migrate')) {
              debugging("jQuery plugin $plugin is part of default installation, it can not be overridden.", DEBUG_DEVELOPER);
          ...
          

          Cheers,

          Gareth

          Show
          Gareth J Barnard added a comment - Dear Andrew Nicols , Thanks , I'm still trying to wrap my head around the $name part of the override code and understand that particular PHP syntax. The check that it's not is based upon the line in the 'jquery_plugin' method: if ($component !== 'core' and ($plugin === 'jquery' or $plugin === 'ui-css' or $plugin === 'migrate' or $plugin === 'migrate')) { debugging( "jQuery plugin $plugin is part of default installation, it can not be overridden." , DEBUG_DEVELOPER); ... Cheers, Gareth
          Hide
          Petr Škoda added a comment -

          Hello, thanks a lot for the feedback!

          1/ I was considering the 'depends' info in plugins.php, for now it is based on order of PAGE->requires->jquery*, we could add it later
          2/ It is not finished yet, I will add unit tests today and complete docs and actually test all the features
          3/ I have used the mymobile theme as an example only, I will create a separate issue for it and post my incomplete changes there in a new branch
          4/ Thanks for reminding me to start using the code checker

          Ciao

          Show
          Petr Škoda added a comment - Hello, thanks a lot for the feedback! 1/ I was considering the 'depends' info in plugins.php, for now it is based on order of PAGE->requires->jquery*, we could add it later 2/ It is not finished yet, I will add unit tests today and complete docs and actually test all the features 3/ I have used the mymobile theme as an example only, I will create a separate issue for it and post my incomplete changes there in a new branch 4/ Thanks for reminding me to start using the code checker Ciao
          Hide
          Petr Škoda added a comment -

          I have updated my branch at https://github.com/skodak/moodle/compare/43bd811...wip_MDL-15727_m25_jquery
          hopefully all mentioned issues were addressed and the mymobile is now in separate commit which will be in separate issue later.

          Now I am testing it and creating draft docs at http://docs.moodle.org/dev/jQuery

          Show
          Petr Škoda added a comment - I have updated my branch at https://github.com/skodak/moodle/compare/43bd811...wip_MDL-15727_m25_jquery hopefully all mentioned issues were addressed and the mymobile is now in separate commit which will be in separate issue later. Now I am testing it and creating draft docs at http://docs.moodle.org/dev/jQuery
          Hide
          Gareth J Barnard added a comment -

          Dear Petr Škoda,

          Given the code:

          if ($component !== 'core' and in_array($plugin, array('jquery', 'ui', 'ui-css', 'migrate'))) {
              debugging("jQuery plugin '$plugin' is part of default installation, it can not be overridden.", DEBUG_DEVELOPER);
              $component = 'core';
          }
          

          and that

          /**
           * Request replacement of one jQuery plugin by another.
           *
           * This is useful when themes want to replace the jQuery UI theme,
           * the problem is that theme can not prevent others from including the core ui-css plugin.
           *
           * Example:
           *  1/ generate new jQuery UI theme and place it into theme/yourtheme/jquery/
           *  2/ write theme/yourtheme/jquery/plugins.php
           *  3/ init jQuery from theme
           * <code>
           *   // file theme/yourtheme/lib.php
           *   function theme_yourtheme_page_init($page) {
           *       $page->requires->jquery_plugin('yourtheme-ui-css', 'theme_yourtheme');
           *       $page->requires->jquery_override_plugin('ui-css', 'yourtheme-ui-css');
           *   }
           * </code>
           *
           * This code prevents loading of standard 'ui-css' which my be requested by other plugins,
           * the 'yourtheme-ui-css' gets loaded only if some other code requires jquery.
           *
           * @param string $oldplugin
           * @param string $newplugin
           */
          public function jquery_override_plugin($oldplugin, $newplugin) {
              if ($this->headdone) {
                  debugging('Can not override jQuery plugins after starting page output!');
                  return;
              }
              $this->jquerypluginoverrides[$oldplugin] = $newplugin;
          }
          

          which is meant to override 'css' with

          $name = $this->jquerypluginoverrides[$name];
          ...
          $plugin = $this->jqueryplugins[$name];
          

          should there not be a guard in the override code to prevent overriding jQuery itself etc.?

          Because I think the following would work:

          // file theme/yourtheme/lib.php
          function theme_yourtheme_page_init($page) {
              $page->requires->jquery_plugin('yourtheme-jquery', 'theme_yourtheme');
              $page->requires->jquery_override_plugin('jquery', 'yourtheme-jquery');
          }
          

          Thus breaking the intent of:

          if ($component !== 'core' and in_array($plugin, array('jquery', 'ui', 'ui-css', 'migrate'))) {
              debugging("jQuery plugin '$plugin' is part of default installation, it can not be overridden.", DEBUG_DEVELOPER);
              $component = 'core';
          }
          

          Cheers,

          Gareth

          Show
          Gareth J Barnard added a comment - Dear Petr Škoda , Given the code: if ($component !== 'core' and in_array($plugin, array('jquery', 'ui', 'ui-css', 'migrate'))) { debugging( "jQuery plugin '$plugin' is part of default installation, it can not be overridden." , DEBUG_DEVELOPER); $component = 'core'; } and that /** * Request replacement of one jQuery plugin by another. * * This is useful when themes want to replace the jQuery UI theme, * the problem is that theme can not prevent others from including the core ui-css plugin. * * Example: * 1/ generate new jQuery UI theme and place it into theme/yourtheme/jquery/ * 2/ write theme/yourtheme/jquery/plugins.php * 3/ init jQuery from theme * <code> * // file theme/yourtheme/lib.php * function theme_yourtheme_page_init($page) { * $page->requires->jquery_plugin('yourtheme-ui-css', 'theme_yourtheme'); * $page->requires->jquery_override_plugin('ui-css', 'yourtheme-ui-css'); * } * </code> * * This code prevents loading of standard 'ui-css' which my be requested by other plugins, * the 'yourtheme-ui-css' gets loaded only if some other code requires jquery. * * @param string $oldplugin * @param string $newplugin */ public function jquery_override_plugin($oldplugin, $newplugin) { if ($ this ->headdone) { debugging('Can not override jQuery plugins after starting page output!'); return ; } $ this ->jquerypluginoverrides[$oldplugin] = $newplugin; } which is meant to override 'css' with $name = $ this ->jquerypluginoverrides[$name]; ... $plugin = $ this ->jqueryplugins[$name]; should there not be a guard in the override code to prevent overriding jQuery itself etc.? Because I think the following would work: // file theme/yourtheme/lib.php function theme_yourtheme_page_init($page) { $page->requires->jquery_plugin('yourtheme-jquery', 'theme_yourtheme'); $page->requires->jquery_override_plugin('jquery', 'yourtheme-jquery'); } Thus breaking the intent of: if ($component !== 'core' and in_array($plugin, array('jquery', 'ui', 'ui-css', 'migrate'))) { debugging( "jQuery plugin '$plugin' is part of default installation, it can not be overridden." , DEBUG_DEVELOPER); $component = 'core'; } Cheers, Gareth
          Hide
          Petr Škoda added a comment - - edited

          Hmm, my intention was to prevent accidental plugin name collisions with core, this may be problematic in future if we decide to add more plugins to default install, so I guess it should be enough to fix the debugging message only:

          debugging("jQuery plugin '$plugin' is included in Moodle core, other components can not use the same name.", DEBUG_DEVELOPER);
          

          The jquery_override_plugin() is intentional action, whoever does it has to face the consequences, I would prefer to not restrict it in any way.

          Show
          Petr Škoda added a comment - - edited Hmm, my intention was to prevent accidental plugin name collisions with core, this may be problematic in future if we decide to add more plugins to default install, so I guess it should be enough to fix the debugging message only: debugging( "jQuery plugin '$plugin' is included in Moodle core, other components can not use the same name." , DEBUG_DEVELOPER); The jquery_override_plugin() is intentional action, whoever does it has to face the consequences, I would prefer to not restrict it in any way.
          Hide
          Gareth J Barnard added a comment -

          Dear Petr Škoda,

          Ta, that actually makes sense as will facilitate a cleaner transitional path for the MyMobile theme whilst providing greater flexibility for all.

          Cheers,

          Gareth

          Show
          Gareth J Barnard added a comment - Dear Petr Škoda , Ta, that actually makes sense as will facilitate a cleaner transitional path for the MyMobile theme whilst providing greater flexibility for all. Cheers, Gareth
          Hide
          Petr Škoda added a comment -

          Submitting for peer review, please note that mymobile conversion commit is there for illustration only, I will create a new issue if we agree this is the way to deal with jQuery in Moodle.

          Show
          Petr Škoda added a comment - Submitting for peer review, please note that mymobile conversion commit is there for illustration only, I will create a new issue if we agree this is the way to deal with jQuery in Moodle.
          Hide
          Martin Dougiamas added a comment -

          The docs looks really good, Petr. If this is suitable for the jquery fans then +1 from me.

          Show
          Martin Dougiamas added a comment - The docs looks really good, Petr. If this is suitable for the jquery fans then +1 from me.
          Hide
          Petr Škoda added a comment - - edited

          Submitting for integration thanks a lot everybody for valuable feedback. Please comment here or create new issues if you find any problem or require some more improvements.

          I have created MDL-38650 for the mymobile theme conversion.

          Ciao

          Show
          Petr Škoda added a comment - - edited Submitting for integration thanks a lot everybody for valuable feedback. Please comment here or create new issues if you find any problem or require some more improvements. I have created MDL-38650 for the mymobile theme conversion. Ciao
          Hide
          Damyon Wiese added a comment -

          I tested this while reviewing the change and the only issue I found is that you have to add the requires->jquery() before you start page output which is different to how the yui includes work. I prefer how it works with the yui includes because you can add your includes at the point of your code that you know they will be required (ie in a specific renderer method).

          Show
          Damyon Wiese added a comment - I tested this while reviewing the change and the only issue I found is that you have to add the requires->jquery() before you start page output which is different to how the yui includes work. I prefer how it works with the yui includes because you can add your includes at the point of your code that you know they will be required (ie in a specific renderer method).
          Hide
          Damyon Wiese added a comment -

          Thanks Petr this has been integrated to master now. I think you have made it quite simple for people to use this which is great.

          Show
          Damyon Wiese added a comment - Thanks Petr this has been integrated to master now. I think you have made it quite simple for people to use this which is great.
          Hide
          Anthony Borrow added a comment -

          Once this issue is closed, would someone who has a better grasp of the work done here mind making a post in the Moodle forums? I find myself wondering if this will interfere with addons that have already implemented jQuery in some fashion and what they would need to do to modify their plugins to make proper use of jQuery. I'll try to take a closer look at http://docs.moodle.org/dev/jQuery to wrap my head around this issue. I just want to understand if there is anything I need to be looking out for when I review plugins for Moodle 2.5. Peace - Anthony

          Show
          Anthony Borrow added a comment - Once this issue is closed, would someone who has a better grasp of the work done here mind making a post in the Moodle forums? I find myself wondering if this will interfere with addons that have already implemented jQuery in some fashion and what they would need to do to modify their plugins to make proper use of jQuery. I'll try to take a closer look at http://docs.moodle.org/dev/jQuery to wrap my head around this issue. I just want to understand if there is anything I need to be looking out for when I review plugins for Moodle 2.5. Peace - Anthony
          Hide
          Petr Škoda added a comment -

          When reviewing add-ons:
          1/ there should be no jQuery, jQuery UI and jQuery Migrate files included
          2/ themes should not manually hack any jQuery JS and CSS
          3/ other plugins should always use PAGE->requires->jquery*

          Show
          Petr Škoda added a comment - When reviewing add-ons: 1/ there should be no jQuery, jQuery UI and jQuery Migrate files included 2/ themes should not manually hack any jQuery JS and CSS 3/ other plugins should always use PAGE->requires->jquery*
          Hide
          Gareth J Barnard added a comment -

          Dear Anthony Borrow,

          I'd be happy to help and make a post in the forums using the MyMobile theme change as an example -> MDL-38650. Just let me know when and what.

          Cheers,

          Gareth

          Show
          Gareth J Barnard added a comment - Dear Anthony Borrow , I'd be happy to help and make a post in the forums using the MyMobile theme change as an example -> MDL-38650 . Just let me know when and what. Cheers, Gareth
          Hide
          Frédéric Massart added a comment -

          Passing, thanks!

          Show
          Frédéric Massart added a comment - Passing, thanks!
          Hide
          Damyon Wiese added a comment -

          Thanks for your hard work. This issue has been integrated upstream and is now available via git (and in some hours, via mirrors and downloads).

          Show
          Damyon Wiese added a comment - Thanks for your hard work. This issue has been integrated upstream and is now available via git (and in some hours, via mirrors and downloads).
          Hide
          Amy Groshek added a comment -

          Petr Škoda Your documentation has samples for including jQuery in blocks and activity modules. These don't appear to work for filters, as page output has already started. Does Moodle have recommendations for loading jQuery and UI from filters? Ideally there is a way to load the scripts only on pages where they're needed, rather than on every page when the filter is enabled.

          Show
          Amy Groshek added a comment - Petr Škoda Your documentation has samples for including jQuery in blocks and activity modules. These don't appear to work for filters, as page output has already started. Does Moodle have recommendations for loading jQuery and UI from filters? Ideally there is a way to load the scripts only on pages where they're needed, rather than on every page when the filter is enabled.
          Hide
          Gareth J Barnard added a comment -

          Hi Amy Groshek,

          I think your question is related to MDL-41516 which was a bug, so filters could have the same issue and require the same sort of fix.

          Cheers,

          Gareth

          Show
          Gareth J Barnard added a comment - Hi Amy Groshek , I think your question is related to MDL-41516 which was a bug, so filters could have the same issue and require the same sort of fix. Cheers, Gareth
          Hide
          Amy Groshek added a comment -

          Thanks so much Gareth J Barnard! Will pursue a solution in following with that issue. The error message is identical.

          Show
          Amy Groshek added a comment - Thanks so much Gareth J Barnard ! Will pursue a solution in following with that issue. The error message is identical.

            People

            • Votes:
              2 Vote for this issue
              Watchers:
              25 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: