Librairie Quiz - Moteur de quiz

Un article de ScriptdigitalWiki.

Jump to: navigation, search

Analyse d'une librairie de quiz pour la préparation aux tests GED - Moteur de quiz


Sommaire

Introduction

Le moteur de Quiz est un cadre d'application qui repose sur PHP et XSLT et les spécifications IMS QTI. Ce moteur de quiz a été principalement conçu pour les GED, mais n'est pas limité à ceux-ci. Pour l'instant, le moteur de quiz ne supporte que les tests de type QCM (Questions choix multiples).

Pour une présentation des objectifs et du mandat à l'origine du moteur de quiz, veuillez vous référer à l'analyse de la librairie Quiz.

La présente documentation s'adresse surtout aux programmeurs.

Concepts à l'origine du moteur de quiz

  • Utiliser la norme IMS QTI.
  • Encapsuler au maximum dans un dossier les fichiers soutenant un seul test.
  • Utiliser la librairie Contrôle Accès pour obtenir des propriétés inhérentes à l'utilisateur (sigle du cours, identifiant de l'utilisateur, courriel de l'utilisateur, type d'utilisateur, etc.).
  • Utiliser la librairie stockagepour la persistance des données.
  • Utiliser XSLT au maximum (avec un peu de Javascript) pour déplacer vers XSLT le plus possible la logique des comportements.
  • Utiliser PHP un comme un 'pipeline' pour gérer XSLT.
  • Fournir aux designers HTML des gabarits XSLT simplifiés qui puissent être facilement modifiables.
  • Utiliser les mêmes fichiers pour tous les tests en recourant à un fichier de configuration pour créer des comportements différents selon le type de tests (par exemple, pour les GED, entre pré et post test).

Présentation du moteur de quiz

Le moteur de quiz utilise XSLT pour générer les fichiers suivants:

  • Pages du test.
  • Pages de correction du test.
  • Page affichant les messages d'erreurs.

Si l'un de ces fichiers est inexistant, le moteur de quiz utilisera XSLT pour générer automatiquement les pages manquantes. Cela permet à un designer de modifier un gabarit XSLT, et de voir immédiatement le résultat de ces modifications. Pour cela, il suffit simplement d'éliminer le fichier qui sera le résultat d'une transformation XSLT antérieure. Le fichier manquant sera donc automatiquement généré par XSLT. Autrement, le moteur de quiz utilise en quelque sorte une cache, ce qui fait que les fichiers existants ne seront pas régénérés par XSLT à chaque requête de l'utilisateur.

Il existe en outre, une option dans le contrôleur du moteur de quiz qui permet de générer via XSLT tous les fichiers nécessaires à un test même si ces fichiers existent (seul un programmeur devrait avoir accès à ce fichier). Cela peut être utile si on doit faire plusieurs modifications aux gabarits XSLT, ou au contrôleur lui-même.

Le contrôleur du moteur de quiz est à /servicesweb2/lib/servicesQuiz/aiguilleur_contr.inc. L'option est la suivante.

# $valide_transfo = 0 pour creer a chaque requete les fichiers du test et de la correction
# $valide_transfo = 1 pour rediriger vers la page.php existante sans passer par XSLT
$valide_transfo = 1;

Description d'une requête

Nous l'avons dit plus haut, un test est un répertoire (figure 2) qui contient la plupart des fichiers utilisés par ce test, nobostant le contrôleur du moteur de quiz (aiguilleur_contr.inc), la librairie Contrôle Accès et la librairie Stockage. Le contrôleur est un simple fichier PHP contenant moins de 400 lignes (code et commentaires).

Supposons par exemple qu'un utilisateur désire effectuer un test situé à l'endroit suivant:

   http://example.org/servicesweb2/sites/GED/test_03/
   

La requête chargera tout d'abord le fichier index.php. Ce fichier ne contient que quelques lignes pour appeler le contrôleur aiguilleur_contr.inc.

<?php
#################################################################
# index.php
# $Date: 2006/10/18 19:33:20 $ - $RCSfile: index.php,v $ - $Revision: 1.1.2.1 $
#################################################################
include ('../../../configurations/global.inc');
include ($ENV_SERVICESWEB[&apos;servicesQuiz_aiguilleur_contr_inc&apos;]);
?>

Le contrôleur aiguilleur_contr.inc effectuera les étapes suivantes (figure 1).

  • Traite le fichier assessmentTest.xml pour obtenir les propriétés du test et les pointeurs vers les fichiers de questions (assessmentItem.xml, ici dans cet exemple, les trois fichiers XML dont les noms commencent par Lect1m07a2_item). Ensuite traite le fichier servicesquiz.xml qui contient les conditions propres au test. Ce dernier fichier pourra contenir les lignes suivantes.

servicesquiz.xml

<?xml version="1.0" encoding="UTF-8" ?>
<servicesQuiz>
    <!-- pré test -->
    <passation reprise="0" suspendre="1" persistance_score="0" /> 
    <!-- post test -->
    <!-- <passation reprise="1" suspendre="0" persistance_score="2" /> -->
</servicesQuiz>

Voici une description des options du fichiers servicesQuiz.xml.

  • reprise: Est-ce que le test peut être repris (0 = pas de reprise, 1 = reprise possible) ?
  • suspendre: Est-ce que le test peut être suspendu (0 = pas de suspension, 1 = suspension possible) ?
  • persistance_score: Est-ce qu'on affiche le score (0 = ne pas afficher, 1 = afficher le score) ?
    • Le nom de cette option risque d'induire en erreur et il faudra le changer car tous les scores sont conservés.

Selon les conditions présentes dans servicesQuiz.xml, le contrôleur aiguilleur_contr.inc décidera de la suite si le test a le statut suivant (figure 1):

  • nouveau
  • reprise
  • suspendu
  • durée --> pas implémentée

Par exemple, un test GED de type pré-test ne pourra pas être repris, mais pourra être suspendu. Dans le cas d'un post test (toujours pour les GED), un test pourra être repris, mais pas suspendu. Dans les deux cas, l'utilisateur peut toujours accéder au test si ce dernier est un nouveau test (jamais vu auparavant par l'utilisateur). On notera que le moteur de quiz ne sait pas s'il s'agit, toujours par exemple dans le cas des GED, d'un pré ou post test. Il ne connaît que les conditions établies dans servicesQuiz.xml. Cela permet une adaptation plus souple du moteur de quiz dans d'autres contextes.

Une fois que les conditions liées au statut du test sont connues, le contrôleur aiguilleur_contr.inc choisira d'afficher ou non le test. Dans un second temps (non implémenté), le contrôleur tiendra compte des conditions qui sont issues d'assessementTest.xml et des fichiers de questions contenu dans les fichiers assessmentItem.xmlqui sont ici nommées Lect1m07a2_item_01/02/03.xml.

Une fois que le test est terminé, le contrôleur aiguilleur_contr.inc déterminera l'affichage (test réussi, test échoué, test avec score).

On notera la différence entre le répertoire de la figure 2 et de la figure 3. En effet, si le test est "joué" pour la première fois, XSLT générera les fichiers manquants (voir la ligne rouge qui montre ceux-ci dans la figure 2).

Les fichiers PHP généré par XSLT sont les suivants (figure 3).

  • page01/02/03.php représentent le questionnaire. Le nombre dépend du nombre de pointeurs vers les fichiers assessmentItem.xml qui sont contenus dans le fichier assessmentTest.xml.
  • correction_ok.php et correction_nok.php sont les fichiers affichant le message lié au résultat du test (réussi, échoué). Si en outre, l'option persistance_score est positive, ces fichiers afficheront le résultat du test.
  • validation.php est le fichier qui affichera les messages d'erreurs liés au statut du test. Ces messages sont les suivants (et pourront être évidemment changé si nécessaire).
    • "Vous ne pouvez reprendre ce test, car celui est terminé." --> (exemple: GED pré test)
    • "Le test ne peut être repris, car il n'a pas été complété." --> (exemple: GED post test - à noter que ce comportement sera modifié et que le test pourra être repris, mais le test sera vierge)
    • "Il faut terminer le test avant la correction. Revenez sur vos pas."; --> (exemple: GED dans tous les cas)

Figure 1:schéma d'une requête

Image:gedrequete.jpg

Figure 2: répertoires contenant un test avant transformation XSLT

Image:gedrepertoirepretest.jpg

Figure 3: répertoires contenant un test après transformation XSLT

Image:gedrepertoireposttest.jpg

Quelques conventions pour les fichiers XSLT

Les fichiers XSLT sont de deux types:

  • XSLT standard (feuille de style)
  • XSLT littéral (Litteral Result Element )
    • Les fichiers XSLT littéraux sont les gabarits qui seront édités par le designer HTML.

Le processus est ainsi.

  • PHP décide du fichier standard XSLT à traiter.
  • Le fichier XSLT standard importe le fichier XSLT littéral qui lui est lié.
  • XSLT fait la transformation et génère le ou les fichiers PHP.

Les fichiers XSLT sont nommés de la façon suivante pour qu'on puisse facilement distinguer entre un fichier XSLT standard et un fichier XSLT littéral.

  • nom_fichier_contr.xsl: contr_ dénote un fichier XSLT standard. C'est à ce fichier XSLT que PHP passera des paramètres.
  • nom_fichier-xhtml.xsl: -xhtml dénote un fichier XSLT littéral qui est importé par un fichier XSLT standard.

D'autres parts, les variables/paramètres présents dans les fichiers XSLT sont nommés en observant les conventions suivantes.

  • param_nom_paramètre: la variable (ici un paramètre pour XSLT) dont le nom est précédé par param_ dénote un paramètre qui est passé par PHP au fichier XSLT standard.
    • Exemple: $param_include_once_config_global
  • contr_nom_variable: la variable dont le nom est précédé par contr_ dénote une variable qui a été initialisée dans un fichier XSLT standard. Cette variable sera passée au fichier XSLT littéral.
    • Exemple: $contr_test_titre
  • nom_variable: la variable dont le nom n'est ni précédée par param_ ou contr_ dénote une variable qui est définie dans le fichier XSLT littéral.
    • Exemple: $item_nomBoutonRadio

Les fichiers XSLT et la génération des fichiers PHP

Comme nous l'avons dit plus haut, nous avons essayé au maximum de déplacer la logique programmatique des tests de PHP vers XSLT. PHP agit donc en quelque sorte comme "pipeline", passant, via des paramètres, certaines conditions liées au fichier servicesquiz.xml aux fichiers XSLT pour que ces derniers génèrent les fichiers PHP conséquent avec le type de test (par exemple, avec les GED, pré et post tests). Notons que le processus décrit ici ne survient que si les fichiers PHP sont absents, ou si l'option $valide_transfo est à '0'. Dans le cas contraire, l'utilisateur est simplement redirigé vers les fichiers PHP existants.

Qu'il s'agisse des pages du questionnaire (page01/02/03.php), des pages liées à la correction (correction_ok.php, correction_nok.php) ou à l'affichage des messages d'erreur (validation.php), le processus est toujours le même. La figure 4 illustre ce processus dans le cas de la génération des fichiers PHP liés aux questionnaires.

  1. Le contrôleur aiguilleur_contr.inc choisit selon la circonstance le fichier XSLT standard auquel il passe les paramètres nécessaires à la transformation XSLT.
  2. Le fichier XSLT standard importe le fichier XSLT littéral qui est un gabarit XSLT/XHTML.
  3. Les pages sont générées par XSLT.

Le questionnaire

La figure 4 illustre le processus concernant le questionnaire.

  1. ged_contr.xsl est choisi par le contrôleur aiguilleur_contr.inc.
  2. ged-xhtml.xsl qui est un gabarit XSLT/XHTML est importé par ged_contr.xsl.
  3. Les pages page01/02/03.php sont générées par XSLT.

Note: On devrait renommer ces fichiers pour ne pas laisser à penser que ces fichiers ne conviennent qu'au GED.

La correction

Test réussi

  1. correction_ok_contr.xsl est choisi par le contrôleur aiguilleur_contr.inc.
  2. correction_ok-xhtml.xsl qui est un gabarit XSLT/XHTML est importé par correction_ok_contr.xsl.
  3. La page correction_ok.php est généré par XSLT.

Test échoué

Même processus que plus haut, on substituera simplement dans le nom des fichier à "_ok" le fragment "_nok" ("not ok").

Messages d'erreur

  1. validation_contr.xsl est choisi par le contrôleur aiguilleur_contr.inc.
  2. validation-xhtml.xsl qui est un gabarit XSLT/XHTML est importé par validation_contr.xsl.
  3. La page validation.php est généré par XSLT.

Figure 4

Image:Transformatikon.jpg

Javascript

Comme nous l'avons mentionné plus haut, nous avons décidé d'utiliser au minimum PHP pour ajouter du dynamisme à la page. Par exemple, même si toutes les pages PHP sont en quelque sorte "dynamiques", car certaines utilisent la librairie Stockage, et toutes devraient utiliser Contrôle Accès, le rôle de PHP s'arrête là (en outre, bien sûr de son rôle de "pipeline"). Par conséquent, Javascript est utilisé pour ajouter des éléments à la page qui peuvent être présents ou non selon le contexte. En général, on se sert de la "query string" (ce qui est après un point d'interrogation) pour passer des arguments qui informeront le Javascript présent dans les pages. C'est le cas pour l'instant des éléments suivants.

En outre, PHP peut passer au fichier XSLT standard un paramètre qui indiquera si doit être présent dans le fichier des questionnaires un script Javascript qui affichera un message disant qu'on ne peut suspendre un test.

Pour résumer, le moteur de quiz communique à Javascript des informations dynamiques soit par la "query string" ou soit par un paramètre xslt.


Suggestion pour améliorer le moteur de quiz

  • Déplacer l'option $valide_transfo vers le fichier de configuration servicesquiz.xml pour que cette option s'applique uniquement à l'intérieur d'un seul test au lieu d'être global à tous les tests comme elle l'est actuellement.
  • Générateur de tests, qui à partir de gabarits, va générer les fichiers XSLT, CSS et Javascript.
  • Génération automatique par XSLT de tous les fichiers PHP sans avoir à passer par les requêtes des utilisateurs si ces fichiers sont absents.
  • Dans les fichiers XML, se servir de xml:lang et implémenter cela dans le traitement fait par le contrôleur aiguilleur_contr.inc.