Attention : vous consultez actuellement la documentation dédiée aux versions 1.x de Moodle. La documentation pour les versions 2.x de Moodle est consultable ici : mod/customlabel/development, celle pour les versions 3.x de Moodle est consultable ici : mod/customlabel/development et celle pour Moodle 4.x est consultable là : mod/customlabel/development.

mod/customlabel/development

De MoodleDocs
Aller à :navigation, rechercher

Retour à l'index du composant

Ce composant est extensible et permet d'ajouter facilement des nouveaux "grains" de contenus préformattés.

Les grains préformatés nouveaux, s'ils permettent d'enrichir les micro-modèles de contenus et favoriser une bonne écriture des contenus de cours, ne seront pas transportable sur une plate-forme qui ne dispose pas de ces sous-modèles (à moins de fournir les sous-types à installer sur la plate-forme d'arrivée).

Les fonctions centrales permettant la prise en charge du sous-type sont mutualisées dans le "noyau" du module Customlabels. La mise en oeuvre d'un sous-type est simple et réduite au strict nécessaire :

  • Description d'un micro-modèle de données (champs d'information élémentaires de l'étiquette)
  • Description des gabarits de sortie (templates HTML)
  • Fichiers de langue et de labels affichables
  • Feuille de style par défaut du sous-composant

Cela se traduit dans l'arborescence suivante :

  customlabel
     -> type
         -> NEWTYPE
             -* customlabel.class.php
             -* customlabel.css
             -> lang
                -> en_utf8
                    -> customabel.php
                    -> template.tpl
                -> fr_utf8
                    -> customlabel.php
                    -> template.tpl

La classe customlabel_type_NEWTYPE

Chaque nouveau type de contenu est représenté par une classe définissant :

  • la liste des champs du micro-modèle interne
  • une fonction éventuelle pre_process() modifiant les valeurs du micro-modèle à des fins particulières (construction d'URLs, récupération de données externes au micro-modèle) AVANT que le rendu du gabarit ne soit calculé.
  • une fonction éventuelle post_process() permettant d'effectuer certaines opérations APRES que le rendu du gabarit ait été calculé.
  • une fonction éventuelle pre_update() permettant d'effectuer certaines opérations AVANT que les modifications de la valeur su champ par l'auteur soit enregistrée.
  • une fonction éventuelle post_update() permettant d'effectuer certaines opérations APRES que les modifications de la valeur su champ par l'auteur soit enregistrée.
  • une fonction éventuelle on_delete() permettant d'effectuer certaines opérations lorsque l'instance de label est supprimée du cours.

La définition des champs

Elle se fait par remodelage du constructeur de la classe.

Voici un exemple d'un type ajoutant deux champs en plus du champ "nom de l'instance" qui est intégré dans le modèle par défaut :

   function __construct($data){
       parent::__construct($data);
       $this->type = 'worktodo';
       $this->fields = array();
   
       $field = new Stdclass;
       $field->name = 'worktodo';
       $field->type = 'textarea';
       $field->rows = 20;
       $this->fields['worktodo'] = $field;
   
       $field = new Stdclass;
       $field->name = 'estimatedworktime';
       $field->type = 'textfield';
       $field->size = 10;
       $this->fields['estimatedworktime'] = $field;
  }

Le traitement préalable avant réalisation

Les gabarits de contenus sont alimentés au moment de la mise à jour (de l'enregistrement) de l'instance de label. Il est possible que certaines transformation de données soient nécessaires. Par exemple, considérons un champ qui permet la sélection de trois secteurs professionnels :

  $field = new StdClass;
  $field->name = 'branchepro';
  $field->type = 'list';
  $field->options = array('batiment', 'transport', 'energie');

et la disponibilité de trois images à placer dans le gabarit de chemin :

  • /mod/customlabel/type/branchepro/batiment.png
  • /mod/customlabel/type/branchepro/transport.png
  • /mod/customlabel/type/branchepro/energie.png

Il serait en effet lourd de fournir les URL complètes en dur à la liste.

La fonction de prétraitement peut servir dans ce cas pour faire cette transformation juste avant d'utiliser le gabarit HTML. On rajoute des nouvelles entrées dans les données disponibles du gabarit ($this->data).

  function pre_processing(){
     global $CFG;
     $this->data->branchepixurl = $CFG->wwwroot.'/mod/customlabel/type/branchpro/'.$this->data->brancheprooption.'.png';
  } 

On remarque l'altération du nom 'branchepro' en 'brancheprooption', car le champ 'branchepro' contient la valeur affichable du choix et non la clef.

L'écriture d'un gabarit

Les gabarits sont des séquences simples de HTML dans lesquelles on place des "balises d'injection" de données. La limite du gabarit est qu'il n'est pas possible de fabriquer des parties "conditionnelles" ou "optionnelles". Si tel est le besoin, il faut produire l'ensemble de la séquence HTML conditionnelle dans une variable $this->data et appeler l'ensemble de la séquence dans le gabarit.

Voici un exemple complet de gabarit :

  <table class="worktodo" cellspacing="0" width="100%">
         <img src="<%%headerimage%%>" />
         Travail à effectuer...
         Type : <%%worktype%%>
         <img src="/mod/customlabel/type/worktodo/clock.jpg" /> <%%estimatedworktime%%>
         <%%worktodo%%>