Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.9.3
    • Fix Version/s: 1.9.4
    • Component/s: SCORM
    • Labels:
      None
    • Difficulty:
      Moderate
    • Affected Branches:
      MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_19_STABLE
    • Rank:
      33000

      Description

      it would be nice if we could write some fancy JS that checked if the SCORM API had been loaded in the clients browser instead of having to wait the set number of seconds in loadSCO.php

      some more info here:
      http://moodle.org/mod/forum/discuss.php?d=109406#p481234

        Activity

        Hide
        Ron Meske added a comment -

        In examining how the player and api load I noticed that the size of the api for SCORM 1.2 is fairly large and the api for SCORM 1.3 is twice the size. To reduce load time, these two javascript files need to be optimized to decrease the size as much as possible. I used an online Javascript Compressor on the SCORM 1.2 api and it ened up being on 1K instead of 31K. Of course, this will require keeping an uncompressed version of the api for editing purposes, but this will greatly speed up the load time of the api.

        Another suggestion, is to change the player and api so that the api is completely loaded prior to loading the SCORM TOC and module. This can be accomplished by separating the creating of these components into individual functions and adding code to the end of the api that triggers the loading of the SCORM TOC and module. This will guarantee that the api is loaded prior to the course looking for it.

        Show
        Ron Meske added a comment - In examining how the player and api load I noticed that the size of the api for SCORM 1.2 is fairly large and the api for SCORM 1.3 is twice the size. To reduce load time, these two javascript files need to be optimized to decrease the size as much as possible. I used an online Javascript Compressor on the SCORM 1.2 api and it ened up being on 1K instead of 31K. Of course, this will require keeping an uncompressed version of the api for editing purposes, but this will greatly speed up the load time of the api. Another suggestion, is to change the player and api so that the api is completely loaded prior to loading the SCORM TOC and module. This can be accomplished by separating the creating of these components into individual functions and adding code to the end of the api that triggers the loading of the SCORM TOC and module. This will guarantee that the api is loaded prior to the course looking for it.
        Hide
        Dan Marsden added a comment -

        Hi Ron,

        thanks for the feedback! - yeah I think there's a range of ways we can verify that the API has been loaded before calling scorm in a much more efficient manner than just waiting a set number of seconds (which is ugly/cumbersome/ and needs to be fixed!) - I'm hoping Piers will get a chance to look at this in the next couple of weeks or so.

        I've added Tim to this bug as he's been doing a lot of optimisation on JS in Moodle recently - Tim I can't remember if there was any discussion on compressing the js? - have you looked at how we might manage this in CVS at all?

        Show
        Dan Marsden added a comment - Hi Ron, thanks for the feedback! - yeah I think there's a range of ways we can verify that the API has been loaded before calling scorm in a much more efficient manner than just waiting a set number of seconds (which is ugly/cumbersome/ and needs to be fixed!) - I'm hoping Piers will get a chance to look at this in the next couple of weeks or so. I've added Tim to this bug as he's been doing a lot of optimisation on JS in Moodle recently - Tim I can't remember if there was any discussion on compressing the js? - have you looked at how we might manage this in CVS at all?
        Hide
        Tim Hunt added a comment -

        There was some discussion, but nothing done yet.

        My preferred solution is mangle JS as part of install/upgrade, so we keep uncompressed JS in CVS - and have a way to turn it off, so developers working on JS are not inconvenienced.

        However, a prerequisite to anything like that is getting all JS into external .js files, and including it all with require_js. The existing require_js API is nice and simple for developers, and yet gives us all the flexibility we need to manage which actual file is included behind the scenes when a developer asks up to include a certain bit of JS, for example switching in a compressed file.

        However, there is first a big job going through the code and making everything use require_js.

        Show
        Tim Hunt added a comment - There was some discussion, but nothing done yet. My preferred solution is mangle JS as part of install/upgrade, so we keep uncompressed JS in CVS - and have a way to turn it off, so developers working on JS are not inconvenienced. However, a prerequisite to anything like that is getting all JS into external .js files, and including it all with require_js. The existing require_js API is nice and simple for developers, and yet gives us all the flexibility we need to manage which actual file is included behind the scenes when a developer asks up to include a certain bit of JS, for example switching in a compressed file. However, there is first a big job going through the code and making everything use require_js.
        Hide
        Dan Marsden added a comment -

        Piers has just pushed a fix into 1.9Stable and HEAD that checks if the API has loaded and redirects much quicker! - improves the user experience a lot! - thanks Piers

        Ron - as Tim mentions, the JS is getting a really good tidy up in HEAD - Thanks for your comments Tim!

        Show
        Dan Marsden added a comment - Piers has just pushed a fix into 1.9Stable and HEAD that checks if the API has loaded and redirects much quicker! - improves the user experience a lot! - thanks Piers Ron - as Tim mentions, the JS is getting a really good tidy up in HEAD - Thanks for your comments Tim!

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: