« Développer un bloc » : différence entre les versions

De MoodleDocs
Aller à :navigation, rechercher
mAucun résumé des modifications
 
(Une version intermédiaire par un autre utilisateur non affichée)
Ligne 1 : Ligne 1 :
[https://docs.moodle.org/3x/fr/Développement_de_plugin | Retour à l'index]
[[Développement de plugins|Retour à l'index du développement de plugins]]


== Pourquoi développer un bloc ?==
== Pourquoi développer un bloc ?==
Ligne 67 : Ligne 67 :
Pendant l'écriture :  
Pendant l'écriture :  


* Ecriture de la définition des données
* Écriture de la définition des données
* Préparation des paquets de langues
* Préparation des paquets de langues
* Si votre bloc utilise du Javascript, préparation des répertoires Javascript (habituellement blocks/block_<nomblock>/js)
* Si votre bloc utilise du Javascript, préparation des répertoires Javascript (habituellement blocks/block_<nomblock>/js)
* Création du fichier de style local blocks/block_<nomblock>/styles.css
* Création du fichier de style local blocks/block_<nomblock>/styles.css
* Ecriture de la classe principale
* Écriture de la classe principale
* Ecriture des librairies locales, le cas échéant.
* Écriture des librairies locales, le cas échéant.


==Construction d'un bloc==
==Construction d'un bloc==
Ligne 84 : Ligne 84 :
   }
   }


La plupart des méthodes sont déjà définies dans les classes de base. Le travail de "forge" du bloc consiste à écrire les méthodes indispensables au cahier des charges du bloc, et de surcharger quelques méthodes dont on veut altérer la réaction contectuellement pour ce bloc.
La plupart des méthodes sont déjà définies dans les classes de base. Le travail de "forge" du bloc consiste à écrire les méthodes indispensables au cahier des charges du bloc, et de surcharger quelques méthodes dont on veut altérer la réaction contextuellement pour ce bloc.


Elle doit nécessairement contenir les méthodes :
Elle doit nécessairement contenir les méthodes :
[[Catégorie:Développeur]]

Dernière version du 11 août 2018 à 16:23

Retour à l'index du développement de plugins

Pourquoi développer un bloc ?

Un bloc est une forme très passe-partout dans Moodle, car le bloc peut s'implanter dans de nombreux contextes de l'interface. Comme élément très polyvalent, il est souvent le premier choix lorsque l'on veut ajouter une fonctionnalité dans Moodle.

La nouvelle gestion des blocs de Moodle renforce notablement cette impression, puisque le bloc peut se positionner sur n'importe quelle page, et que leur réglage permet de les faire apparaître de manière plus ou moins systématique dans des contextes et des sous-contextes.

Nonobstant, il existe autour du bloc un certain nombre de principes et de limites qui pilotent certains aspects du choix :

  • Un bloc, dans la plupart des formats standards, se place principalement dans les zones de mise en page (layouts) réservés aux blocs, c'est à dire :
    • Les zones escamotables (docks)
    • Les colonnes de gauche ou de droite.

Il n'y a que dans des formats non standard tel que les formats paginés, où le bloc peut prendre presque toutes les positions. (Les formats paginés assemblent les pages par blocs et ramènent l'expression des activités dans des pseudo-blocs).

  • Un bloc ne dispose d'aucune API pédagogique :
    • Pas d'API en relation avec le carnet de notes
    • Pas d'API en relation avec le suivi des accomplissements
    • Pas d'API en relation avec la conditionnalité d'affichage

Il est évidemment possible artificiellement, d'accrocher le fonctionnement d'un bloc à de telles données, mais il devra le faire à travers la coopération avec une activité.

  • Un bloc reste un élément contextualisable par instance (on peut en créer plusieurs qui auront une existence séparée.
  • Un bloc reste un élément "partie de" l'environnement qui le reçoit (page de cours, page d'administration, etc.)

En général on choisit de développer un bloc :

  • Pour faire du monitoring de données (bloc affichage) : On a quelques données à rendre compte à l'utilisateur sous des conditions diverses
  • Pour donner accès à un module applicatif plus important (bloc "porte"). En général cette application est une fonctionnalité transverse à la plate-forme, ou latérale par rapport au cours.
  • Pour faciliter la navigation (bloc liens)
  • Pour ramener des raccourcis ou des utilitaires à portée de clic (bloc proxy)
  • Comme accessoire d'un ensemble plus important regroupant un ensemble divers de plugins coordonnés.

Localisation et forme du bloc

Tous les blocs se situent dans le répertoire /blocks de la distribution de Moodle, et sont matérialisés par un répertoire. Informatiquement, le bloc est une classe dérivée de l'une des classes de bases définies dans le fichier /blocks/moodleblock.class.php

  class bloc_base{
  }

pour les blocs affichant un contenu HTML quelconque, ou

  class block_list{
  }

Pour les blocs affichant un contenu sous forme d'un liste de liens avec ou sans icône. Moodle 2 à introduit une nouvelle classe de base pour les affichages de liens en organisation hiérarchique :

  class block_tree{
  }

dont se sert notamment le nouveau bloc "Navigation".

Plan de travail

Voici ce que vous aurez à faire pour construire votre bloc :

Avant l'écriture :

  • Déterminer si votre bloc a besoin d'un modèle de données propre
  • Déterminer si votre bloc va appliquer des droits et aura des réactions différents en fonction de certains utilisateurs
  • Déterminer si votre bloc va appliquer des règles de styles particulières à certaines sorties qu'il produit
  • Déterminer si votre bloc adopte des variantes de comportement qui nécessitent un paramétrage instance par instance (paramétrage d'instance)
  • Déterminer si votre bloc peut adopter des variantes de comportement d'une installation Moodle à l'autre (paramétrage global)
  • Déterminer si votre bloc définit des services réseau (mnet)
  • Déterminer si votre bloc définit des événements (events)
  • Déterminer si votre bloc nécessite, au moment de l'installation, une transformation de données (ou un traitement sur des fichiers). Les blocs qui altèrent fortement des données "standard" sont vivement découragés par la communauté. Dans tous les cas, si votre bloc "installe" quelque chose, il doit être en mesure de désinstaller l'ensemble de ces données et restaurer la situation de données à l'identique comme s'il n'avait jamais été présent.

Pendant l'écriture :

  • Écriture de la définition des données
  • Préparation des paquets de langues
  • Si votre bloc utilise du Javascript, préparation des répertoires Javascript (habituellement blocks/block_<nomblock>/js)
  • Création du fichier de style local blocks/block_<nomblock>/styles.css
  • Écriture de la classe principale
  • Écriture des librairies locales, le cas échéant.

Construction d'un bloc

La classe principale représentant le bloc constitue le fichier principal du bloc, nommé block_<nomblock>.php dans le répertoire de bloc.

cette classe porte le nom du bloc :

  class block_<nomblock> extends block_base{
     ...
  }

La plupart des méthodes sont déjà définies dans les classes de base. Le travail de "forge" du bloc consiste à écrire les méthodes indispensables au cahier des charges du bloc, et de surcharger quelques méthodes dont on veut altérer la réaction contextuellement pour ce bloc.

Elle doit nécessairement contenir les méthodes :