Other Notes

A Few Notes on Well-Behaved SCORM Content

  • Avoid having your content reference other windows outside of the content, especially _top. Similarly, avoid trying to close the current window. SCORM compliant LMSs are free to launch content in whatever manner they choose. Quite often this means that content is launched in a frameset and referencing the _top window or trying to close the current window may result in an error. Also, do not make any assumptions about the size of the window your content will be launched in. Calling the ConcedeControl function with the SCORM_RECOMMENDED exit behavior setting is the best way to exit a course. Some LMSs require specific behaviors on exit, in these situations, you may have to change the exit behavior setting in the Configuration.js file.
  • Be sure to close any windows that you open before exiting the content. The onunload event is useful to ensure that all child windows are closed before the content is exited.
  • Try to space calls to the API evenly throughout the content and avoid bunching a lot of calls at the end of the content (especially in the last onunload event). Many LMSs require a round-trip between the client and server every time a value is saved to the LMS. Many calls grouped together may take a while to execute and may not all get processed when invoked from an onunload event. Especially when using the AICC standard, try to call the CommitData function well before the content is unloaded.
  • Be sure to list ALL necessary files in the SCORM manifest. Some LMSs only make available the files that you list regardless of what exists in your content directory.
  • Avoid using any server-side code in your content. SCORM content is meant to be packaged and physically transferred to any LMS. Since different LMSs run on different platforms, you cannot count on a particular server-side technology being available when your content is distributed. All dynamic content should be either generated on the client-side or re-written as static HTML. Please contact us for help with this transition.

The Cross Domain Scripting Problem

As a workaround to not knowing what technologies are available on a remote LMS, many content vendors want to host SCORM compliant content on their own servers to preserve access to server-side scripting. While this is technically possible, it is very difficult to make work properly.

The problem you run into is called the “Cross Domain Scripting Problem” or “3-Node Problem”. Essentially when two HTML pages are loaded in a frameset (or parent/child browser windows), script in one frame can only reference script in the other frame if the two frames originated from the same domain (due to browser security restrictions). Since SCORM relies on cross-frame/window scripting for communication with the API, content served from one server will not be able to communicate with an LMS served from a different server.

There are several workarounds to this problem, most of which are complex to administer. One option is to trick the browser into thinking that the content and LMS are actually coming from the same domain by modifying the DNS entries on both servers. Another option involves putting a portion of the LMS or a portion of the content on the other server and writing a non-standards-based communication interface. Please contact us if you would like help developing a 3-node solution.

When deploying content as AICC you have more options for circumventing the problem. One option includes running a server-side page on the content server that relays information to and from the LMS server. An example of this solution is included in the AICC Relay directory. Another solution is to fall back on a write-only mode in which data is saved to the LMS, but data cannot be read back from the LMS. Driver will automatically fallback to a write-only mode if it is deployed in an AICC cross domain environment.

results matching ""

    No results matching ""