Il s'agit ici d'un scénario d'intégration dans lequel un composant (block_publishflow) transportant des cours entre plusieurs plates-formes Moodle a besoin d'effectuer un certain nombre d'opérations “post-transport” pour recaler certains paramètres et dispositifs du cours à son nouvel environnement. Le scénario ci-dessous décirt le besoin d'opération suite à la mutualisation d'un cours à partir d'une plate-forme A dans un moodle collecteur de mutualisation B.
Parmi les opérations à réaliser :
Note : Ce scénario est en application sur les plates-formes moodle académiques du Rectorat de Rennes et de la plate-forme Atrium Paca.
En l'absence de MoodleScript, l'ensemble de ce scénario devrait être codé en PHP avec un appel à des API complexes de gestion de fichiers Moodle, les API de role, l'API de catégorie de cours. les API d'inscriptions plus du code spécifique pour le traitement des blocs.
L'estimation de ce développement est de plus de 800 lignes de code et il ne sera pas adaptatif.
La séquence Moodlescript écrite pour effectuer le postprocessing du cours après restauration est :
ENROL current IN current AS editingteacher USING manual ASSIGN ROLE deployer TO current IN current REMOVE BLOCK course_recycle FROM current ADD ENROL METHOD profilefield TO current HAVING profilefield: profile_field_enseignant profilevalue: 1 role: deployer ADD CATEGORY PATH ":userhostname/:userfullname" IN idnumber:ARRIVALS IF NOT EXISTS HAVING idnumber: ":userwwwroot_:username" MOVE COURSE current TO runtime:idnumber:":userwwwroot_:username" BACKUP COURSE current FOR publishflow
Compte tenu des implicites de contexte courant suivants :
Le script est invoqué dans une instance de moteur de script par le composant block_publishflow qui en a pris le contrôle. Dans ce contexte le bloc publishflow injecte dans la machine de script les contextes ad hoc suivants :
Le script est contenu dans une variable de configuration globale du composant block_publishflow. Il est donc amendable et extensible à tout moment.