A reader has identified a problem with Rev 1.0 of the IMS Manifest File Reader which causes the parser to fail when there’s a resource that doesn’t have any files associated with it. Rev 1.1 corrects this bug. The only changes are to the resolveIMSManifestDependencies() function in subs.php, and deal with the case where $file is not an array.
| You can download the code bundle using this link. |
All other details – including system requirements – are the same as for Rev 1.0.
Time to run a few tests. I start with the test case that I’ve been using since Step 3. Just to make sure that everything is working, I run it part-way through then close the window using the ‘x’ at the top of the window to make sure that my LMSCommit() and LMSFinish() calls are operating as expected.
I’ve addressed handling of the LMSSetValue() and LMSGetValue(), LMSCommit(), and LMSFinish() calls. The remaining piece of the puzzle is to look at how the RTE is initialized.
In Rev 1 of the code, the course/SCO call to LMSInitialize() caused an AJAX request to be sent to the server where a script called initialize.php was executed. The one thing that this doesn’t do is to transfer all of the data element values from the database into the local cache. In theory, I could simply use one or more additional AJAX calls to transfer the data from the server to the local cache. But I think there’s a better way.
In theory, the way that I handle the LMSFinish() API call should be pretty much the same as for Rev 1 of my code. I simply generate an AJAX request to the server which runs a PHP script that carries out a series of actions on the data elements stored in the LMS database (persistent storage). But the use of the cache introduces some wrinkles.
The LMSCommit() API call is a little more complicated, but it bears a strong resemblence to the way that I handled LMSSetValue() in Rev 1 of the code – see this post for more details. What I’m going to do is to create a POST request and submit it to the server. But, where the old LMSSetValue() code only passed one variable value across, here I’m going to be passing all of the SCO-writeable data element values.
Unless I’m missing something obvious, reading from and writing to the cache is pretty simple – certainly a lot simpler than the AJAX calls that I was having to make! Here’s how I’m going to handle it.
I’m grateful to reader ‘Legend’ who suggested that I use a JavaScript object as a cache rather than a set of variables. So my cache would look like this:
Time to sketch out the structure of my caching RTE code. Just to recap, here’s the current version of the VSSCORM RTE which has no caching mechanism – all transactions are immediately reflected in the persistent storage (LMS database).
Over the last couple of weeks, I’ve had some very useful feedback and suggestions for the future direction of my project. And I’d like to thank everyone for the suggestions – I’m certainly going to try to address them going forwards.
However, there’s another problem that I need to address first. I’ve been using a system based on the VSSCORM RTE for some time, and it’s been working very well. But recently, I came across a SCORM 1.2 course (SCO) that caused the system to run really slowly. So I need to find out why.
