I’ve implemented revised versions of my LMSGetValue() and LMSSetValue() functions. It’s time to check the other functions to see if there’s anything that I need to do right now.
My last couple of posts talked about setting up the SCORM RTE API to submit requests to the LMS server using AJAX. Now I have to set up something on the server end to receive and process those requests. Remember that I’m not talking about a real LMS server here – just something to mimic the most primitive behavior of a SCORM-compliant LMS.
The LMSSetValue() function is very similar to the LMSGetValue() function that I described in my last post except that we might have a problem with the amount of data that we’re transferring to the server.
In my last post, I talked about how to create the JavaScript XMLHttpRequest object that I need to send information to the server, and read the server’s response. Now, I’m going to integrate that with the API code that I created earlier in the api.html file. I’m going to start with LMSGetValue(). This is what the new LMSGetValue() function looks like.
I’m not going to make this a tutorial on AJAX – you may want to do some background reading on it before we go much further. Or you can just take what I say on trust … it’s up to you.
An AJAX request is a JavaScript object. The way that the object is created depends on the browser that’s being used (sigh!) since Microsoft implements it using an ActiveX object, and other browsers have a native implementation. So I need to test for the browser when I create the request object.
Fortunately, there’s a lot of code out there that will save me the effort of developing it myself – see, for example, this excellent tutorial provided by IBM. Here’s my version.
Now that I have the basic SCORM RTE API (lots of acronyms!) and the “imaginary LMS” database table in place, I have to start looking at how to link them together.
The SCORM RTE API is implemented as a client-side application i.e. it uses JavaScript in the student’s browser. This is the cause of a host of problems which I won’t get into right now, and is one of the reasons why I designed the (server-side) LM-Light course/LMS interface standard a few years ago.
But, I’m trying to build a SCORM interface here, so I do have to deal with one problem right now, and that’s making JavaScript “talk” to the LMS server, and “listen” to the data coming back from that server. In other words, I have to make the student’s browser write data to the LMS server database, and read data from the same database. And this isn’t as simple as it seems.
I’m going to create a database table in my imaginary LMS to hold the SCORM variables without worrying too much about what they mean. I’ll simply store the variable name and variable value that the course passes to the API LMSSetValue(varname,varvalue) function.
As I noted before, I’m going to use MySQL for my database since that happens to be what’s readily available to me. But there’s nothing specific to MySQL in what I’m going to be doing.
Just a brief aside … I’d forgotten about this SCORM Primer from Philip Dodds at ADL.
It’s a pretty high-level overview of the subject but might help you see how the SCORM RTE – the subject of the work I’m describing right now in this blog – fits in with SCORM as a whole.
You might also find useful information in the ADL Community SCORM section.
Now that I’ve got the frameset and a skeletal API in place, I think I’ll try running a SCORM course and see:
This will provide some good guidance on where to go next.
OK – I’ve got the basic frameset in place, so I now need to create the HTML page that will hold the SCORM RTE API calls. Just to remind you, there are 8 JavaScript functions that the LMS must provide so that the course can communicate with it.
This is pretty easy – I’ll create the HTML file called api.html as I’ve defined it in the RTE frameset. Then I’ll add the following code:
