The Runtime Environment in a Nutshell
Un LMS conforme a SCORM è necessario per implementare un’API composta da 8 funzioni (vedere la Sezione 3.3 del documento SCORM Runtime Environment per le specifiche complete) a cui il contenuto può accedere per comunicare con l’LMS.
- LMSInitialize()
- LMSFinish()
- LMSGetValue()
- LMSSetValue()
- LMSCommit()
- LMSGetLastError()
- LMSGetErrorString()
- LMSGetDiagnostic()
Questa API è implementato da ciò che il SCORM definisce una API Adattatore. Un adattatore API deve risiedere in una finestra che è una finestra di apertura o un frame padre della finestra che contiene il contenuto. Ciò significa che LMS può avviare il contenuto in una nuova finestra o in un frameset. L’adattatore API deve essere un oggetto ECMAScript (JavaScript) denominato “API” accessibile tramite il DOM. L’adattatore deve implementare le 8 funzioni sopra elencate.
Tutte le comunicazioni tra il contenuto e l’LMS sono gestite da questo adattatore, quindi l’autore del contenuto non deve preoccuparsi di comunicare con il server, deve solo essere in grado di trovare l’adattatore API ed effettuare le chiamate JavaScript appropriate. Questa separazione tra client e server è essenziale per SCORM in quanto garantisce la portabilità del contenuto costringendolo a funzionare su una piattaforma standard (il browser web). È importante notare che il contenuto può comunicare solo con LMS tramite questo adattatore API JavaScript. Non esiste un metodo conforme a SCORM per la comunicazione dei contenuti con LMS tramite altri metodi, come i servizi Web o le richieste HTTP.
Per una conformità SCORM minima, l’unica cosa che un contenuto deve fare è chiamare LMSInitialize() all’avvio e quindi chiamare LMSFinish() quando esce. Può essere così semplice.
Nel mondo reale, però, vogliamo un’interazione molto più ricca. Vogliamo essere in grado di segnalare i risultati dei test, tenere traccia del tempo, segnalibro nostra ultima posizione e altro ancora. Questo è dove le prossime tre funzioni entrano in gioco. Lo SCORM definisce un modello di dati costituito da elementi del modello di dati da cui il contenuto può leggere e scrivere, facilitando questo tipo di funzionalità (vedere la Sezione 3.4 del documento sull’ambiente di runtime SCORM per un elenco completo degli elementi del modello di dati). LMSGetValue() recupera il valore di un elemento del modello di dati dal LMS, LMSSetValue() scrive un valore per un elemento del modello di dati al LMS e LMSCommit () può essere chiamato dopo che tutti i valori sono impostati per garantire che i dati sono persistenti.
Ad esempio:
cmi.core.lesson_location è l’elemento dati che descrive la posizione dell’utente nel contenuto
Quando inizia il contenuto (dopo aver chiamato LMSInitialize ();), potrebbe voler effettuare questa chiamata per scoprire dove l’utente ha interrotto e riportarlo a quel punto:
strLastLocation = objAPI.LMSGetValue("cmi.core.lesson_location");
Quando il contenuto va in un’altra area, potrebbe effettuare questa chiamata per salvare la posizione dell’utente:
blnSuccess = objAPI.LMSSetValue("cmi.core.lesson_location", "page3"); blnSuccess = objAPI.LMSCommit("");
Le altre tre funzioni consentono al contenuto di intrappolare e gestire in modo intelligente gli errori.
L’implementazione di questo adattatore API nell’LMS è un po ‘ più complicata rispetto all’utilizzo dal contenuto. L’adattatore API deve implementare tutte le funzioni API e supportare la maggior parte del modello di dati SCORM. Il problema complicato coinvolto nell’implementazione di un LMS conforme allo SCORM è come gestire la comunicazione da browser a server. Molte persone scelgono di farlo con un’applet Java, ma altri hanno avuto successo usando Flash, controlli ActiveX e JavaScript puro.