I want to carry a couple of basic tests within LMSSetValue and LMSGetValue to see:
- whether the specified data element is supported; and
- whether it has the necessary read or write privileges
and then set the error code appropriately. This is a pretty minimal set of tests – I’m probably going to have to add some others later – but it’s a starting point. Here’s the code.
One of the things that has caught me out in a couple of recent cases is that the SCORM standard makes SCO developers rely on error codes to determine whether or not certain elements are supported. I describe one specific example in an earlier post – Step 54 – Error Handling.
In a sensible system, the initialization process would provide the SCO with a complete list of supported elements so that it wouldn’t have to go through all this rigmarole. But that’s too much to hope for, so I need a simple way to check whether a data element is supported or not, and I’ll also need to check whether it’s readable and/or writeable.
The three API functions that return information to the SCO can now be connected to the error code variable that I implemented in Step 58, and to the error messages that I set up in Step 57.
OK – an easy step here. I want a place to store the error code, so I introduce a new variable called ‘errorCode’ into api.php.
The SCORM 1.2 Runtime Environment (RTE) uses a system of error codes that are set by the API, and which can be read by the SCO using three API functions:
I’ve already implemented “stubs” for these functions in my api.php code as noted in Step 10 – Other SCORM API Fuctions. But, before I make these functions active, I need to set up the error codes and related messages in the API code.
It’s been a while since I last posted to the VSSCORM blog which is both good news – the services that I’ve set up using the VSSCORM code have been running pretty successfully – and bad news – I haven’t been moving the development forward as quickly as I’d like.
Now, it’s time to start up again and tackle a couple of issues that I’ve been wanting to deal with:
- error codes and error messages;
- a logging capability to help diagnose SCO to LMS communication problems.
So, with that in mind, in my next post I’m going to start attacking the error codes and messages.
I don’t refer to the PHP manual very much for commonly used functions, so I almost missed this one. The ‘mysql_escape_string’ function that’s used in subs.php to prepare data for insertion into the database is deprecated as of PHP 5.3 and should be replaced with ‘mysql_real_escape_string’.
But, recently, reader ‘deighvan’ reported a similar problem and, even better, came up with a simple solution. So I’ve incorporated a slightly modified form of this solution in a new version of the rte.php file.
The problem SCO described in Step 52 is now working correctly, so why do I need to look any further? There’s a more subtle problem.
The ‘datamodel.element._children’ mechanism described in the SCORM RTE specification seems to have been developed so that there’s a way for a SCO to determine which data elements are supported.
You can now follow the progress of VSSCORM on Twitter – search for username VSSCORM, or click on this link: http://twitter.com/VSSCORM