Valery Fremaux

Merci Fred, ça donne du coeur à l'ouvrage.

Je ne pense pas que ce module ci (c'est marrant j'ai toujours envire d'écrire "moodule", mais ce serait intraduisible dans d'autre langues pourrait répondre directement à ce que tu exprimes, mais il est certain que ton intervention me fait avancer sur le domaine, et sur l'idée d'un module approprié qui jonglerait avec les désirs d'apprentissage de l'élève et les nécessités d'un programme de connaissances.

Je pense aujourd'hui qu'il nous faut approfondir la notion de parcours, peut-être basée sur la notion de WorkPlan comme ce projet de getion de projet technique le laisse à imaginer. Mais ce dispositif que je termine est parfaitement cadré dans des pratiques normatives en gestion de projet (je pense aux standards de l'IEEE, organisation mondial des ingénieurs en éléectricité, électronique et informatique, qui savent depuis de nombreuses années quels sont les concepts clefs de la conduite d'un projet technologique.

Des idées ou métaphores apparaissent, bien sûr, comme les idées de livrables ou d'étapes, mais ce ne sont que analogies formelles qu'il va falloir retravailler sérieusement : si la communauté technique peut être guidée par les concepts que j'évoque, si leur sens commun se reconnait ici par rapport à d'autres "outils" du même type (SourceForge, Microsoft Project), cette reconnaissance (que j'espère facile) emprunte à des habitudes "métier" (je m'y suis basé dessus d'ailleurs, je n'ai strictement rien inventé que de mettre en scène une pratique de travail connue -- wellknown -- et effectuée de facto dans nos enseignements). 

Oui, le schéma des rôles est encore un peu nouveau pour moi qui ne travaille avec une 1.7 qu'en développement et exploite encore sur une 1.6.4 (j'attends la fin de l'année scolaire pour basculer).

Je m'appuie donc là sur l'API qui est reprortée de version en version, à charge du noyau de fournir la méthode pour conserver son focntionnement pérenne.

Je me pencherai prochaînement sur la façon dont on pleut exploiter des rôles plus riches dans un module, probablement en "publiant des permissions assignables", plutôt qu'en "supposant existants la définition de certains rôles", ce qui serait une induction abusive à mon avis.

Jusqu'à présent, les deux distinctions que je fais sont issues du schéma "historique" et conviennent à une grande majorité de cas pour un module pédagogique géré entre un enseignant et les étudiants du cours.

Si le nouveau schéma de rôles est très intéressant par la souplesse qu'il permet, trouver ses applications demande de la réflexion et du doigté (comme toujours). Seules certaines applications spécifiques et très contextuelles ont réellement besoin d'autant de souplesse. 

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') ne 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 whysiwhyg.

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 champ :

• 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 activté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 prochaîne 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édamment) 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édent 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. 

Le prochain article traitera de la constitution "standard" d'un module.

2 ème Phase : La préparation du développement

Une fois qu'un module est bien ce que l'on cherche à réaliser, et avant de commencer à ouvrir le capot, on peut commencer par une étude du "modèle propre"  du module, c'est-à-dire, de sa modélisation fonctionnelle indépendante du contexte. Les méthodes sont multiples, mais le minimum à apporter est plus ou moins :

• un modèle de classes (objet) ou un modèle d'entités relationnelles (tables) dans lesquelles on installe systématiquement une clé primaire comme une colonne nommée 'id', de type entier plus ou moins grand selon l'entité de donnée. On peut commencer par des INT ce qui est une garantie de taille suffisante dans la plupart des cas, et on pourra réduire après. Le modèle de classes (de type UML) n'est là que pour donner également la structure des tables. On pourra le cas échéans faire des classes PHP avec, mais ce type d'applicatif ne tire pas un avantage faramineux de la programmation objet (on verra plus tard qu'on peut utiliser une pseudo techniqe objet, dite "objets informels" ou "opportunistes" que PHP permet.
• des scénarios d'usage de ces données, basés au moins sur 2 rôles minimum :
  • étudiant => if (!isteacher($course->id))
  • enseignant => if (isteacher($course->id))

C'est un modèle de départ très simpliste, auquel on ajoutera rapidement des altérations, par exemple lorsqu'il y a une stratégie de groupe.

• des scénarios d'écrans, dans lesquels "ce qu'on aimerait voir" est maquetté. De ce visuel (on appelle ça une démarche "user-driven").

Pour ce qui est des scénarios, il existe plusieurs cas de figure :

• Les modules à scénario séquentiel présentent un seul écran à la fois à l'utilisateur qui dépend de la phase de l'activité. Cette phase est gérée par rapport à un ensemble de champs datés dans l'enregistrement principal du module (discussion qui suivra sur le modèle de données d'un module). exemple typique : assignement (Devoir)
• Les modules "pseudo-application" présentent une petite "web application" à l'intérieur du portail. On peut naviguer dans des écrans complexes via une barre d'onglets (super pratique à programmer, même pour une héirarchie à deux ou trois niveaux -- discussion à suivre sur ce pattern ). Exemple typique : les quizz, côté enseignant.

Il peut être enfin utile de préparer des maquettes HTML des formulaires simples, bien qu'il soit plus rentable de recopier des séquences déjà écrites dans d'autres modules (prochaine discussion pour vous dire dans quel fichiers trouver des séquences intéressantes).

Bon, trop tard pour continuer, et je déménage un copain demain matin à 8h00

Moodlement vôtre.

VF