This is an old revision of the document!
Les feuilles de styles xml, fournissent des formats (disposition) et un certain fonctionnement (modèle d'interaction).
Le format de fiches le plus simple et très souple avec un corps de type BODY sans contexte ni lien dans une première version. Pour fabriquer des questions de défis non standard et des ateliers de géométrie avec geoGebra ont été ajoutés: une section LINK (ajoutée le 12.11), le contexte interface/tex (ajouté 01.13) et les contextes controle/poids et controle/penalite (ajoutés 06.13). [à étudier la convergence entre qtml.xsl et general.xsl et le double emploi avec les modèles 'fiche', 'applet', etc.].
Le format qtml-1 ajoute les cartouches et qtml-2 utilise un élément “CONTENT” pour le contenu (à mettre à jour selon la nouvelle version de qtml).
Exemples: geometrie/geo-met-ps.xml ; defis/n52-def1.xml
Format de fiches, prévu, selon les variantes pour des feed-back et actions spéciales.
Variantes:
Ces modèles sont utilisés pour initialiser des séries d'activités. Ils utilisent des contextes spéciaux dont l'action s'étend sur toutes les activités de la salle.
Si une autre activité est également logée dans la salle, il est prudent d'y mettre le contexte 'super' de SCHEME 'mode' à 'standard' (<CTXT NAME=“super” SCHEME=“mode” VALUE=“standard”/>). En principe inutile (été 2013, voir la rubrique dispositif).
De plus vtml-1d initialise des variables “réservées” (qui seront supprimées dès que possible comme cela a été fait pour vtml-1t, plus récent).
Format prévu pour enregistrer des réponses fill-in avec plusieurs automatismes à disposition (envoi des IDREF en cas de réponse juste, fausse, etc.). La réponse juste (ou un message) est enregistrée dans parent.locReponse.
Les variables nécessaires au problème sont dans l'élément VARLIST. Le mode de calcul de la réponse est lié aux attributs du formulaire FORM-REP (voir WebMath-history.pdf).
Dans le cas où la réponse est une simple formule celle-ci est contenue dans la variable (LOC) 'modele'. Il est possible de manipuler ce modèle ce qui peut réduire l'écriture de scritps de réponse (voir problem2/sphere-cone1.xml). Dans ce cas il est possible d'ajouter un contexte 'tolerance' ou 'pct-tolerance' (dans les autres modèles 'tolerance' accepte la valeur 5%, ce qui n'est pas possible dans l'état actuel du modèle qrep).
Il est possible d'ajouter des champs de réponse voire des interactions souris en écrivant les scripts adéquats et d'implémenter la fonction verifReponse().
Le cas échéant il appartient au script d'une interaction de mettre la variable parent.locReponse à ”” pour éviter un commentaire erroné lors de feed-back ultérieurs.
Sous modèles
Différentes maquettes, sous-modèles existent:
Attention: certains sous-modèles concernent le type d'expertise, d'autres la présentation (par exemple: le sous-modèle tableau figurait dans le contexte expert/dom à changer en interaction/type=qrep et intraction/mode=tableau !
LINK à implémenter
Scripts associés: En tant que modèle principal, les procédures de contrôle de réponse se trouvent dans les scripts de base de la salle (salle.jx). Pour les autres modèles un fichier script spécifique existe.
Divers:
Propose des suites d'items avec expertise pour la correction ou l'aide
LINK à implémenter
Scripts associés (expertises): proport.js (exemple: problem1/ui_1898.xml), prop-achat.js (cpi/exe-monp03.xml), mesure.js (ateliers/m61-add.xml)
Ce modèle permet de remplir plusieurs zones (fill-in). Les réponses données sont “évaluées” de même que les réponses attendues (cela permet de faire varier des paramètres conduisant à la réponse, par exemple le taux de change). Exemple: qcm3/ui_prob1.xml, problem1/ex-change-05.xml, ateliers/ca-def2.xml (défi) (attention si une fonction est donnée comme réponse avec un paramètre textuel, il faut que celui-ci soit obligatoirement marqué par \'). Il est possible d'insérer une information après la lacune (par exemple: l'unité) (élément COMPL) (voir $XML/geometrie/a-carre2.xml). De même que le séparateur entre demande et réponse (voir $XML/qcm1/calc-base2.xml). Voir aussi $XML/defis/n31-def2.xml et $XML/defis/n54-def1.xml pour une version avec données aléatoires ! (à remplacer encore la copie de COMPL par un 'apply-templates' afin de pouvoir traiter l'élément VAL-VAR, comme cela est fait pour ENONCE et FORM-REP dans QUESTION. Le désavantage de cette opération est de devoir déclarer tous les éléments pouvant figurer dans COMPL).
Sous-modèle: pythagore, triangle, change, arithm
LINK à implémenter
Scripts associés: qrep-mult.js
Exemples: voir ci-dessus, problem1/exe-trigo-eq1.xml pour une exploitation non standard du séparateur, problem1/exe-trigo-eq1r.xml pour un bricolage pour PI.
Ce modèle fournit un modèle d'interaction. Un calcul est flashé. Il s'agit de répondre soit la valeur exacte (une tolérance peut être accordée) soit la meilleure estimation dans un temps le plus court possible (mais un tempo 'infini' est possible).
Les calculs peuvent être préparés ou alors générés de façon aléatoire. Dans ce dernier cas, le contexte 'remise' donne le nombre de calculs à proposer (N ou perpete).
En mode défi ce modèle est un peu particulier dans la mesure où il ne permet pas des essais. La tolérance est liée à la performance réalisée.
Met à jour : defi, diag,
Contextes
Lors de l'usage dans les défis
LINK à implémenter
Scripts associés: flash.js
Ce modèle propose des qcm classiques avec réponse unique ou multiple. Exemple: itinerai/nu_pb7.xml, ateliers/g41-def1.xml (défi). Le modèle peut-être paramétré par: type 'qrep' et mode 'qcm/checkbox' ou 'qcm/radio' (obsolète). Nouvelle version: type 'qcm' et mode 'checkbox' ou 'radio' (voir $XML/qcm0/vect4.xml ou geo-met-ps-exe3.xml). A ajouter d'autres modes ('defile', etc.). Il est possible de préciser la largeur de la colonne contenant les choix (à mettre sur tous les items, à améliorer en utilisant les param de XSL).
LINK à implémenter
Scripts associés: qcm.js
Todo: désactiver le bouton de validation lorsque l'exercice est terminé.
Ces modèles sont classés dans les flash (utilisés plutôt en tempo 'infini')1). Les réponses sont données avec la souris. Le premier comptabilise chaque réponse séparément, l'autre cumule les réponses (de plus permet de modifier les emplacements des zones d'activité). (A regrouper)
LINK à implémenter
Scripts associés: touchpad.js
Exemples: qcm0/ui_cc01.xml (touchpad), qcm0/angle-r1.xml (touchpad, mince), cpi/exe-monp10.xml (touchpad2) (à faire une version avec fenêtres paramétrables, cf qcm/defile-gen).
Les items sont affichés un à un plutôt que d'être tous présents. Le nombre d'items à présenter est mis dans le contexte sous remise. Ce n'est pas judicieux. A mettre plutôt dans une variable LOC (si on prend toute la liste, pas de problème !
LINK à implémenter
Scripts associés: qcm-defile.js
Exemples: demo/nu_df3-1.xml
Ce modèle généralise le modèle flash. Il permet de:
La partie des commandes n'est pas paramétrées. A terme ce modèle pourrait être englobé dans le modèle activite-2 (l'aspect qcm n'étant qu'un type d'interaction parmi d'autres.
Le nombre d'items à proposer qui peut être inférieur ou dans le cas aléatoire supérieur au nombre d'énoncés est dans la variable LOC 'nb_exe'. Si cette variable est mise à 0 ou $undef, la longueur de la liste est prise.
L'ancien modèle qcm/defile devient celui dont expert/dom vaut 'coup-oeil' qui est aussi la généralisation de flash.
Contextes
Le contexte controle/ordre fixe l'ordre de présentation des items:
Le contexte controle/data précise comment les données se trouvent dans les variables LOC. Il peut prendre les valeurs:
Le contexte controle/type_data précise comment les listes sont structurées, les valeurs peuvent être:
Le contexte controle/relation donne la relation de comparaison dr == ga (égalité stricte) dr = ga (égalité avec problème d'arrondi), dr ~= ga, dr > ga.
LINK à implémenter
Scripts associés: qcm-defile-gen.js et les scripts “expert” (master-mind.js, coup-oeil.js).
Le modèle qcm/define est rendu obsolète par cette nouvelle version (avec expert/dom='coup-oeil') qui n'est pas entièrement compatible. Si le souhait est d'adapter les exercices de qcm/define à ce nouveau modèle, voir demo/nu_df3-1.xml et demo/nu_df3-2.xml .
Exemple: demo/nu_df3-2.xml (coup-oeil, valeur); logique/mini-mm2-1.xml (master-mind) ; geometrie/rec-form1.xml (coup-oeil, nom) ; logique/apt-num0?.xml (coup-oeil, valsn, valss)
LINK à implémenter
Ce modèle inaugure le contexte interaction/langage qui permet de 'tu' ou le 'vous'. A ajouter aux contexte la possibilité de paramétrer la grandeur des zones d'affichage.
Scripts associés: qcm-img3.js
Exemples: $xml/demo/cc03.xml ; $xml/puzzle/ffp1.xml
Ce modèle gère des puzzles et des 'memory' (memory/1: classique ou, memory/2: des carte appariées). Se voulant pour des activités d'ouverture, le module de suivi est implémenté dans ce modèle mais il ne peut pas encore figurer dans des défis.
Dans chaque cas, les informations à donner dans le contexte sont : le nombre de lignes et de colonnes, le format des images (largeur, hauteur), le nom générique (kName) des images, le répertoire (kPath) et l'extension (kExt) (par défaut jpg est utilisé (gif pour le dos des cartes !)).
Les images sont à mettre dans $html/$package>/images/$kPath. Dans le cas de memory $kName{0}.gif est le dos des cartes. Les images sont $kName{i}.jpg (et $kName{i}a.jpg lorsque la 2e carte de la paire est différente dans le cas de memory/2).
Dans le cas de puzzle/1, les images commencent par $kName{0}.jpg , $kName{1}.jpg, etc. Pour fabriquer les pièces du puzzle, on pourra s’aider d’un « splitter » (par exemple : ImageCut ou la fonction appropriée de GraphicConverter ou le splitter en ligne http://imagesplitter.net/).
Les cartes sont disposées dans l'ordre de haut en bas et de gauche à droite.
Exemples: $xml/demo/memory.xml ; $xml/demo/memory2.xml ; $xml/demo/puzzle.xml ; $xml/puzzle/fder.xml
Le modèle fiche sert de support à des schémas, parfois dynamiques, créés par une applet Java ad hoc. Peu utilisé, désuet.
Le modèle fiche2, est un support à applets Java. Principalement utilisé pour l'ancienne version du modèle Lacune.
Exemples: $XML/mathbas2/prob-ate.xml ; $XML/demo/ge002.xml ; $XML/jeux/course.xml
A noter que le modèle simple qtml est souvent utilisé pour utiliser des applets (notamment avec la nouvelle philosophie geogebra d'introduire l'applet .ggb sous forme de données).
A revoir course.xml (agrandir les zones ! fait 28.02.15).
Une version 2 (activite-2.xsl) permet le paramétrage des zones et de convoquer des experts pour les différentes interactions (le modèle qcm-defile-gen est pris pour exemple avec lequel le modèle activite-2 pourrait se rapprocher).
Exemple: $XML/logique/master-mind.xml
Scripts associés : activite-2.js, master-mind-jeux.js
Le script général activite-2.js qui devrait gérer les exercices et les défis est à compléter !
Ce modèle n'implémente que la structure d'une page: titre, contextes (CTXT), variables (VARLIST), links (LINKS) et scripts (SCRIPT). Le contenu est constitué d'une introduction (élément INTRO), et de trois “frames internes” (DIV): gen-consigne, gen-cadre, gen-controle. Les scripts sur la page sont réduits au minimum, initialisation de variables et une fonction init_local() qui va faire appel à une fonction affichant le document afficheDocument(<parametre>).
Les contextes interaction/type et interaction/mode indique les scripts à charger qui vont peupler les frames internes en utilisant les informations délivrées par les autres contextes et les variables. Des scripts standard, notamment le “dépouillement” des contextes et variables font l'objet d'une bibliothèque à part (encore à étendre).
Il n'est pas impossible que tous les modèles puissent être chapeautés par ce méta-modèle.
La version utilisant la feuille lacune.xsl et les applets est (momentanément ?) abandonnée au profit d'un usage de la nouvelle feuille general.xsl (et l'interaction est programmée en javascript).
Link à implémenter
$DOC/lacune1/aide-lac.htm décrit les fonctionnalités.
Contextes
Variables locales
Javascript
Content
Voir les exemples.
C'est une suite d'image montrant un algorithme ou une construction. Un slide-show peut être une suite d'images (voir $DOC/rev-bjn/nb-a041.htm) ou une suite d'images avec une légende (voir $DOC/geometrie/tha-part.htm). Dans les deux cas, il faut cliquer sur l'image pour passer au “slide” suivant.
Une version améliorée permet de mettre plusieurs images ($DOC/geometrie/a-composite.htm). Attention à la numérotation des images si d'autres images que l'image du slide sont sur la page (voir $DOC/geometrie/a-disque.htm ou $DOC/mathba1b/det3-cal2.htm).
Une résolution est proposée pas à pas sous forme de texte (sans image ni construction) ($DOC/problem2/prob-aire1-h.htm). Pour un usage plus sophistiqué (style et utilisation de variables locales) voir $XML/mathba1b/ui_1deg1a.xml ; $DOC/mathba1b/ui_1deg1a.htm).
Une version avec cumul des pas existe ($DOC/mathbas1/meq-11-res?.htm), améliorée en paramétrable avec scripts dans guide.js ($DOC/repete/r87-app-1.htm). A intégrer tous les guides dans ce fichier ?
Dans la même idée, il est possible de montrer une construction GeoGebra pas à pas (avec ou sans commentaire). (voir $XML/geometrie/c-geoII-tha.xml et $DOC/geometrie/ate-tha1.htm). (Voir aussi $XML/geometrie/c-geoI-ate1.xml et $DOC/geometrie/ate-base1.htm pour une version plus simple).
Version (permettant les commentaires seuls, mais gérant la mise à zéro d'une zone geogebra) : voir $DOC/geometrie/ate-pyt1.htm.
Nouvelle version ($DOC/geometrie/ate-pol2.htm) avec la possibilité de regrouper plusieurs actions dans des procédures. Les noms procédures sont précédées de @ pour les distinguer des commandes directes de GeoGebra.
Voir $XML/situatio/pion-st2.xml pour une utilisation de $DOC/scripts/wz_jsgraphics.js”
Voir $XML/ateliers/nu-dc23.xml pour une utilisation de la bibliothèque plus récente $DOC/scripts/jsDraw2D.js
A vérifier la sortie d'une version de IE implémentant une bibliothèque graphique native (élément canvas de Firefox).