Gérez proprement vos modules avec la programmation orientée objet
Dans cet article, nous allons vous présenter une méthode pour ranger les fonctions dans vos modules en utilisant la programmation orientée objet (OOP).
Composition d'un module Drupal
Dans un module, toutes les fonctions sont préfixées par son nom et se retrouvent dans un fichier appelé ton_module.module. Ainsi et afin d'éviter de se retrouver avec des dossiers trop volumineux, les développeurs ont plutôt l'habitude de construire des petits fichiers ton_module.*.inc, chacun ayant une responsabilité unique. Pour utiliser une fonction de ces fichiers, plusieurs possibilité s'offrent à vous :
- Mettre une require_once au début du fichier .module
- Commencer par module_load_include() à chaque fois où vous avez besoin de la fonction
- Charger le fichier automatiquement : le cas avec hook_menu(), hook_theme() etc.
Focus sur les méthodes statiques
Si vous travaillez avec Drupal depuis un certain temps déjà, vous devriez connaître tout cela. Mais si nous voulons aller encore plus loin, nous pouvons mettre les fonctions dans des classes sous forme de méthodes statiques. Ici, les avantages sont les suivants :
- L'autoload de toutes les classes : pour cela, vous pouvez mettre les fichiers dans le .info dans les lignes files[] = ..., ou écrire votre propre class loader
- L'utilisation propre de l'espace de nom : ce n'est pas forcément une nouvelle fonctionnalité du PHP 5.3 (car il arrive que vous utilisez encore la version 5.2). Ici, vous n'avez pas besoin de préfixer les méthodes dans vos classes. Votre intelligent IDE (vim l'est aussi) vous donnera des suggestions plus pertinentes. Par exemple, si vous travaillez sur un projet "vous", avec 20 modules "vous_module1", "vous_module2"..., dans chaque module vous avez des fonctions vous_module1_fonction1, vous_module1_fonction2... Ainsi, lorsque vous taperez "vous", votre IDE va suggérer 10 fonctions qui sont toutes dans le premier module vous_module1. Nous sommes d'accord, cela n'est pas vraiment pertinent. Avec les classes séparées, votre IDE présente d'abord des classes, puis les méthodes quand vous complétez le nom de classe. Plus pratique !
Les méthodes enveloppées dans des classes ne pollue pas le scope global, elles aident aussi pour le refactoring ou le protypage ou le test. Mais l'article est trop long, donc j'arrête. Quand même, avant, pour l'info, ce paradigme est utilisé récemment dans Drupal 7 avec la classe FieldInfo (par yched et al.) et c'est très bien. Il n'y a alors pas de raison pour ne pas l'utiliser.
PS : un article sans code, mais allo quoi.
- ton_module.inc : function ton_module_faire_1() {} function ton_module_faire_2() {}
sera :
- TonModule.php : class TonModule { public static function faire_1() {} public static function faire_2() {} }
-
Conception webTester l'envoi d'emails en local avec une configuration offline pour ApacheCe tutoriel s'adresse aux développeurs d'applications web qui souhaitent configurer leur environnement local pour tester l'envoie d'emails sans passer par un serveur smtp externe.
-
Conception webDrupalCon Amsterdam - Episode 2 : Etat des lieux sur Drupal Commerce 2019Toujours dans le sujet de la dernière DrupalCon qui s'est déroulée à Amsterdam en octobre dernier, focus sur l'actualité de Drupal Commerce.
-
Conception webDrupalCon Amsterdam - Episode 1 : Drupal en route vers sa version 9Du 28 au 31 octobre dernier, avait lieu l'événement incontournable de la communauté Drupal : la convention DrupalCon Amsterdam 2019. Et comme chaque année depuis plus de 10 ans, l'équipe d'Axess était présente.