Implémentation des series et évaluations en v2
Un article de DocAstairs.
Sommaire |
[modifier] Introduction
Ce document présente la démarche et les consignes à suivre pour l'implémentation des séries, listes, tests de positionnement, évaluations et leurs corrections associées pour le front office v2.
[modifier] Les réperoires
Les répertoires concernés, ainsi que leur role, sont les suivants:
- liste: affichage des élements communs aux séries et listes de tests de positionnements et à leurs corrections associées.
- serie: affichage des élements spécifiques aux séries et à leurs corrections associées.
- positionnement: à venir
- evaluation: affichage des élements communs à toutes les évaluations (qcm, sondages, qsrc, ftb) et à leurs corrections associées.
- ftb:affichage des ftbs et de leurs correction
- question_reponse:affichage des élements communs aux qcm, sondages, qsrc et à leurs corrections associées.
- question_reponse_element:affichage des élements communs aux questions et réponses et à leurs corrections associées.
- qcm: affichage des qcm et de leurs correction
- sondage:affichage des sondages et de leurs correction
- qsrc:affichage des élements communs aux qrc, src, et à leurs corrections associées.
- qrc:affichage des élements spécifiques aux qrc, et à leurs corrections associées.
- src:affichage des élements spécifiques aux src, et à leurs corrections associées.
Chacuns de ces repertoires contiend l'architecture classique des modules astairs, à savoir les répertoires:
/templates /obj /tpl /script includes.php
[modifier] Les objets graphiques
[modifier] Noms des objets
Chacun des objets graphiques (/templates/obj) devra respecter la convention de nommage associée, à savoir commencer par "guiFo". Un découpage des pages, indiquant les noms des objets et leur role, est fournis dans le document annexe "W3C Refonte du FrontOffice, Elements graphiques partie 2".
[modifier] Héritages des objets
Ils devront tous hériter de la classe PageComponent ou d'un objet héritant de cette classe.
[modifier] Prototypes et contenus des classes
[modifier] Prototypes constructeurs
Voici un prototype "type" d'un constructeur d'un objet graphique (classe guiFoSerieContenu):
function guiFoSerieContenu($block_target,$obj_DoEtape,$module_root=null,$templates=null){ }
Ce prototype présente ici les arguments minimaux que doit avoir un objet:
- $block_target: le nom de la variable de tpl dans lequel va s'afficher cet objet. Cette variable est facultative, car utile uniquement pour l'affichage de blocs dans une boucle.
- $obj_DoEtape : l'objet contenant, ou permettant d'obtenir les variables nécesaires à l'objet graphique. Ici, c'est un DoEtape car il est nesscéaire d'avoir des données concernant l'avancement. Si ce n'était pas le cas, et que seules des données concernant l'étape (classe Etape) étaient nécessaires, on passerait un objet Etape $obj_Etape par exemple.
Il faut toujours passer l'objet le plus "petit" possible. Passer l'objet DoFormation par exemple serai une erreur. Passer l'id, le libellé, etc, serait aussi une erreur et on perdrait l'interet de l'objet.
- $module_root: le chemin du repetoire ou l'on peut trouver les TPL
- $templates : le(s) template(s) à utiliser
[modifier] Contenus des constructeurs et méthodes pour l'héritage
Certains éléments graphiques se ressemblent énormément, par exemple, un QCM et sa correction. On peut voire la correction d'un QCM comme l'affichage d'un QCM plus sa correction. Ce qui ce traduit en développement par un héritage. Ainsi, pour cet exemple, on a : QcmCorrection hérite de QCM. $this->setComponent('actions', $component,true,$this->getBlockName(),$this->getBlockVar()); Un héritage classique suffit, sauf pour les boucles. En effet, une boucle impose une construction particulière. Pour que cet héritage puisse se faire, if faut donc que la classe mère (ici QCM) soit construite d'une certaine façon pour pouvoir être héritée par la suite (par la classe QCMCorrection)
La doc concernant l'héritage des objets graphiques: Recommendations_techniques#Les_objets_graphiques_.28gui_et_templates.29