Moving SCORM API from XAJAX to jQuery

Yesterday I finished a 20 hours job of moving the SCORM API in Dokeos 1.8.6 from XAJAX to jQuery. The problem with XAJAX is that version 0.5 represents an important change in comparison to version 0.2, that version 0.5 is the only one implementing synchronous AJAX calls, and that upgrading was obviously going to take me some time (possibly very long).

We also decided to go with jQuery uniformally in Dokeos 1.8 and 2.0, so I decided, following a suggestion by Eric Marguin, to move it to jQuery.

The problem there is that, if jQuery allows you to execute GET/POST requests easily, the documentation isn’t clear as to how to pass array variables to the resulting PHP script. So I had to implement a array-serializer of my own. The result looks something like this ugly piece of code:

params=”;
params += ‘lid=’+lms_lp_id+’&uid=’+lms_user_id+’&vid=’+lms_view_id;
params += ‘&iid=’+lms_item_id;
obj_string = ”;
for (i in item_objectives){
obj_string += ‘&objectives[‘+i+’]=’;
obj_temp = ‘[‘;
for (j in item_objectives[i]) {
obj_temp += item_objectives[i][j]+’,’;
}
obj_temp = obj_temp.substr(0,(obj_temp.length-2)) + ‘]’;
obj_string += encodeURIComponent(obj_temp);
}
params += obj_string;
$.ajax({
type: “GET”,
data: params,
url: “lp_ajax_save_objectives.php”,
dataType: “script”,
async: false
});

Where item_objectives is an indexed array.

All in all, the implementation seems to work much better than the previous one (because the async: false param allows me to set the AJAX query as synchronous), but I still want to test it a little more before integrating it into Dokeos.

For the curious about the changes applied, they can be seen in an SVN branch: http://dokeos.svn.sourceforge.net/viewvc/dokeos?view=rev&revision=17130

Testing interactions in Dokeos SCORM tool

Because one of the most complicated tools in Dokeos is the SCORM tool (found in dokeos/main/newscorm/ ), and because I am currently checking the inner-workings of the interactions inside this tool (Dokeos version 1.8.5), I thought it would be good to write down, once and for all, how I actually check whether the tool is right or wrong, and whether the content is actually the culprit or not.

Getting the right tools

The elementary tools for these tests are Firefox (I recommend version 3 for its better handling of JavaScript debugging) and its excellent Javascript debugging extension by Joe Hewitt: Firebug.

Getting Firebug installed in Firefox is easy (download and restart Firefox), and activating it for your current Dokeos portal is just a matter of clicking the little cockroach icon in the bottom-right corner of your browser and choosing to activate the “Script” feature.

Setting the breakpoints

Now that you have the right tools all setup, you need to go inside a SCORM learning path inside Dokeos, then select the script you actually want to check. This is done through the “Script” tab in the Firebug window, and picking the right script. You need to pick “scorm_api.php” here, because although it ends with a “.php” extension, it is actually a dynamically created JavaScript script. Furthermore, it is the SCORM API, so this is where all messages from the SCORM content are passed to Dokeos.

What you want to do now is to set breakpoints, where the JavaScript will halt, report on the current status of a few variables, and ask you to confirm that you want to go on before doing anything else.

In this case, we want to test SCORM interactions, so what we’re interested in here is how the SCORM content sets and gets interactions-related variables through the JavaScript code. There are only one getter and one setter in the SCORM API. Namely, LMSGetValue() (around line 127) and LMSSetValue() (around line 323). Because interactions are things that are only written (and never queried), what we’re most interested in is the LMSSetValue() part. That is, if you want to put a breakpoint on interactions in LMSGetValue(), you will find there are only two related calls: one for cmi.interactions._count and one for cmi.interactions._children. You can put a breakpoint on these two cases but it is likely that will not help you much.

So what we want is to put some logging (huh… some breakpoints, sorry) on the interactions case in LMSSetValue(), that is around line 372.

Setting a breakpoint on the line:

if(myres = param.match(/cmi.interactions.(\d+).(id|time|type|correct_responses|weighting|student_response|result|latency)(.*)/))

will have the great benefit of showing us if a call to set an interaction goes through, and at the same time of giving us some information on what information the call bears (we get to analyse the param variable here).

Let’s have a look…

Trying it

Now of course, you will need a SCORM content that sends interactions to try this out, and you’ll need to be sure it actually sends interactions (otherwise your test is pretty much useless).

Now trigger some interactions recording, and see what Firebug shows in its rightmost frame. You should see variables and their values appear there. Do they use the right parameters names? (there is a list of recognized parameters in the scorm_api.php script, line 372 – quoted above)

If you want to go to the next step, simply click the green “play” triangle.

Result types

In my case, the problem I found was that the setting of interactions actually started at interaction ID 1, whereas the setting of interactions should start at “0”. It could be argued that Dokeos, to avoid errors in this case, should prefill all the interactions between 0 (included) and the given interaction ID, and I think this is the way to go. I will check in the SCORM documentation first to make sure this is an option.