Developpement de module : Etape 3
3° étape : Constituer et implanter le modèle de données pour le module
Normalisation du modèle
Une fois votre propre modèle de données constitué, nous allons le normaliser pour Moodle :
- Chaque table DOIT avoir une clef primaire nommée 'id', la librairie de manipulation des enregistrements utilise souvent ce présupposé.
- Les noms de colonnes sont écrits de préférence en minuscules, et non en "minuscules majusculées" (comme en Java, par exemple). Je fais pour ma par une seule entorse à ce régime, lorsque le champ est une clef étrangère sur un Id numérique ou je garde le suffixe Id majusculé : projectId ... mais c'est pâ bien, pour les puristes.
- Les noms de colonne ne sont pas abrégés. On utilise de préférence des mots entiers, ou des suites de mots entiers.
- On préfère que les clefs étrangères soient placées en début de table, juste après la clef primaire, et avant les attributs qualifiants.
- Les booléens ne sont pas des ENUM('Y','N') ni ENUM('VRAI','FAUX') ni ENUM('true','false'). Les booléens sont codés en TINYINT à valeur 0 ou 1.
- Toutes les dates sont encodées en timestamp unix sous forme d'un INT(10).
- Toutes les descriptions sont des champs TEXT, qui recevront le contenu d'un éditeur WYSIWYG.
Règles moins impératives :
- Lorsqu'un champ TEXT est créé pour de la rédaction libre, on devrait créer immédiatement un champ de format de type entier pour mémoriser le format de rédaction pour ce texte. Moodle permet de rédiger en whysiwhyg, mais également dans des formats de balisage simplifiés proches du WiKi ou en HTML basique.
Jeu de tables d'un module
Le jeu de tables d'un module est en grande partie libre. Il existe cependant deux ou trois règles à suivre :
Il existe dans chaque module une table nommée :
{$CFG->prefix}{modulename}
(exemple, si le préfixe est le préfixe par défaut 'mdl_' : mdl_techproject). Cette table contient les paramètres mémorisés pour chaque instance (une instance est obtenue à chaque fois qu'on insère un module d'activité dans un cours).
Cette table contient trois catégories de champs :
- Les champs obligatoires :
- INT(10) id auto_increment UNSIGNED PRIMARY KEY : l'identifiant numérique d'instance
- INT(10) course UNSIGNED : la clef étrangère sur le cours où l'instance est implantée
- VARCHAR(255) name : le nom qui apparaît dans le "layout" du cours et dans le sommaire des activités de ce type.
- TEXT description : la description qui apparaît en face du nom dans le sommaire des activités de ce type.
- Les champs conseillés (ils apparaissent dans de nombreux modules et induisent des fonctionnements standard) :
- INT(10) {modulname}start
- INT(10) {modulename}end : Ces deux dates induisent une validité en temps limité du module.
- INT(10) timemodified : Cette date enregistre la date de dernière modification des paramètres d'instance.
- Les autres champs :
Ils stockent les paramètres et options propre à l'instance et dépendant de la sémantique du module. Pou la plupart, ils seront déterminés au fur et à mesure que vous construirez le module. Il s'agit de tout ce qui peut paramétrer le fonctionnement du module, activer ou désactiver certaines fonctionnalités, proposer des alternatives fonctionnelles à l'enseignant.
Nous reviendrons probablement sur ce modèle pour implanter quelques fonctionnalités standard telles que la notation de l'activité dans une prochaine discussion.
Les autres tables contiennent le jeu de données propre d'une instance particulière : Leur nom est formé ainsi : {$CFG->prefix}{modulename}_{tablesuffix},
ou {tablesuffix} est une séquence de mots minuscules séparés par des '_' : exemple mdl_techproject_assessment, ou mdl_techproject_task_status.
Leur clef primaire est la colonne
INT(10) id
comme introduit dans les règles générales.
Elles ont toutes* une clef étrangère
INT(10) {modulename}
(ou {modulename}id, pour ceux qui veulent expliciter les clefs étrangères) si vous comptez exploiter le mécanisme des groupes, ajouter une clef étrangère INT(10) group (ou INT(10) groupid pour les mêmes raisons que précédemment) permet d'isoler les valeurs de données groupe par groupe.
(*) On peut imaginer que quelques tables n'aient pas cette clef étrangère, lorsqu'on désire partager quelques informations entre toutes les instances. Mais ceci est rare et on préfèrera probablement un fichier de configuration local au module si ces paramètres sont d'ordre techniques.
Y a t-il des tables standardisées ?
Pas vraiment, mais il est toujours conseillé de regarder comment les développeurs précédents ont fait pour que le développement du module reste "dans l'esprit". Par exemple, si vous comptez noter l'activité avec un système d'évaluation élaboré, rassembler les notes dans une table {$CFG->prefix}{modulename}_assessment, n'est pas une mauvaise idée.
Où implanter le modèle de données
En général, vous constituez le modèle de données dans votre implantation de développement. La technique habituelle est l'utilisation d'une application de gestion du modèle de données, comme phpMyAdmin pour la base de données MySQL.
Les fonctions d'export de phpMyAdmin permettent (en exportant la structure et/ou les données) d'obtenir la séquence de requêtes SQL qui permettent la création du modèle de données dans une nouvelle base.
Il faut enregistrer cette séquence dans le fichier mysql.sql (pour la base MySQL, mais d'autres bases sont prises en charge). Le fichier mysql.php servant à programmer les mises à jour après la première mise à disposition du module.
ATTENTION : Vous ne devez pas oublier de remplacer votre préfixe local par la mention prefix_ en tête des noms de tables. Ainsi, si vous avez créé une table :
mdl_monmodule
dans une installation standard pour développer, n'oubliez pas de renommer toutes les occurrences du nom 'mdl_monmodule' par 'prefix_monmodule' lors de la constitution de votre fichier mysql.sql.
