Step 5 – Making JavaScript Talk and Listen to a Server

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.

Here are some of the ways in which I could try to implement this:

  1. A form in a hidden frame (or iframe).
  2. Java.
  3. AJAX.

Here are the pros and cons to each as I see it.

Form in a Hidden Frame

  • Needs only JavaScript so should work in most browsers.
  • Difficult (but not impossible) to queue the requests for sequential execution. Needs a lot of programming.

If I had an HTML form in a frame somewhere in the frame/window hierarchy, I could code the JavaScript RTE API calls (principally LMSSetValue and LMSGetValue) so that they changed the values of form fields in the HTML form and submitted it to the LMS server for processing. Then, when the page refreshed, I could read the data.

This sounds pretty good in principle but, when I tried out some simple experiments using this technique, I ran into a host of problems. The problems stem from the fact that the course was submitting a series of LMSSetValue and LMSGetValue calls in quick succession – far quicker than the LMS server was able to respond. So I would have to set up a queueing system of some kind, and that sounds kind of complicated. Not my first choice!

Java

  • Many organization firewalls filter out Java.
  • I can’t code in Java.

JavaScript can be made to interact with Java applets, and Java applets can interact with a server. So string them together and we have a potential solution. In fact, this is the way that many commercial LMS packages handled the problem in the past and, I’m sure, many still do.

The downside to using this technique is that support for Java is patchy (I’ve dealt with some organizations who simply don’t allow it at all, and many others who filter out Java applets at the firewalls). But, worst of all, I don’t know Java very well. So that would make it a lot more difficult. Perhaps there’s another option?

AJAX

  • Needs only JavaScript …
  • … but students have to have a ‘modern’ browser.
  • Complicated to program?

AJAX stands for ‘Asynchronous JavaScript and XML’, and is the technology behind a lot of the whiz-bang Web 2.0 applications that everyone seems to be using these days. It allows a web page to use JavaScript to communicate with a server and change parts of the web page without re-loading the whole page.

Although AJAX was designed for asynchronous use i.e. multiple requests from the same page where one doesn’t have to wait for another to finish, it can be used in synchronous mode i.e. waiting for one request before another starts. This would suit the sequential nature of the calls that my course is going to make to the LMS e.g. writing persistent data to the database then reading it back into the course to make sure that it has been written correctly.

The downside of using AJAX is that it will require my students to have browsers that will support it. According to [this page], the following browsers support AJAX:

  • Microsoft Internet Explorer 5 and above
  • Mozilla Firefox 1.0 and above
  • Netscape version 7.1 and above
  • Apple Safari 1.2 and above.
  • Opera 7.6 and above
  • Konqueror
  • Chrome

This list doesn’t seem very restrictive to me – for example, I haven’t come across a client requiring support for anything earlier than Internet Explorer 6 for quite some time. So I’ll assume that I’m OK here and simply add another “Ground Rule” to the rules that I defined in an earlier post:

Assume that students are using a modern browser that can support AJAX.

My final concern about AJAX is that I don’t know how difficult it will be to program. But I’m not going to know until I try! I’m going to start by experimenting with AJAX and, if that doesn’t work, I’ll backtrack and take another look at the alternatives.

Further Reading

There’s a lot of information out there about AJAX and I’m sure that Google will point you to an explanation that suits you. But, if you’re looking for a starting point, perhaps you could try this series of articles from IBM on Mastering Ajax.

This entry was posted in Run Time Environment. Bookmark the permalink.