Avec la sortie de Drupal 8, Le CMS se rapproche de l’objet en intégrant des composants Symfony. Quels sont les principaux changements pour les utilisateurs de Drupal ? A quoi ces composants servent-ils ?
Salah Meharga, CTO de SensioLabs, a bien voulu répondre à nos questions et nous éclairer sur le sujet.
SensioLabs : Bonjour Salah ! Tout d’abord, quels sont les changements principaux de Drupal 7 à Drupal 8 et qu’est-ce que cela va changer pour les utilisateurs du CMS ?
Salah Meharga : Avant de parler de Drupal 7 et 8, un petit rappel historique s’impose.
Drupal, à l’origine (version 5 et 6), était très orienté code procédural. Depuis la version 7, ils ont essayé d’introduire un peu plus de POO (Programmation Orienté Objet) notamment avec l’API de la base de données. Ce passage vers la POO se faisait à petit pas parce qu’un mode procédural était quand même maintenu afin de ne pas avoir de rupture brutale avec les habitudes des développeurs Drupal.
Dans Drupal 8, avec l’arrivée de Symfony, le CMS s’est beaucoup plus orienté vers la POO. Notamment avec l’arrivée des Controlleurs ainsi que du conteneur d’injection de dépendance.
Aujourd’hui, un développeur Symfony aura beaucoup plus de facilité pour entrer dans un projet Drupal, car les composants Symfony y sont utilisés sans une réelle couche d’abstraction.
Quels sont les avantages forts de Symfony dans Drupal 8 ?
Un des principaux avantages est de se rapprocher des solutions du marché. Tous les Framework modernes ont par exemple un composant de routing. Même s’il n’y a pas de standard défini, il y a un mode de fonctionnement qui est commun à tous les frameworks. Drupal grâce aux composant Symfony a rejoint ce mouvement.
Ensuite, le conteneur d’injection de dépendance est sûrement la plus grosse valeur ajoutée de Symfony dans Drupal : c’est ce qui permet de réutiliser n’importe quelle fonctionnalité de n’importe quelle partie du code. C’est quelque chose qu’il manquait à l’outil.
C’est donc la standardisation du développement qui permet à celui qui connaîtra l’objet et Symfony de pouvoir développer plus facilement. A l’inverse, si quelqu’un a fait du Drupal toute sa vie et arrive sur Drupal 8 l’adaptation peut être compliquée. Symfony apporte cette uniformisation du code qui facilitera le prise en main.
Tu nous as dit que les principaux composants de Symfony étaient inclus dans Drupal 8. Quels sont-ils et qu’apportent-ils aux projets Drupal 8 ?
Les principaux composants utilisés sont :
Console, DependencyInjection, EventDispatcher, HttpFoundation, HttpKernel, Routing, Serializer, Translation, Validator, Yaml…
Les composants Symfony sont à l’image du framework : ils apportent de l’extensibilité et de la flexibilité.
Comme je l’ai cité plus tôt, le conteneur d’injection de dépendance permet de réutiliser n’importe quelle fonctionnalité développée dans Drupal à n’importe quel endroit du code. Le fait d’avoir un conteneur qui contient le nom de toutes ces fonctionnalités-là permet d’aller voir ce conteneur et de dire « je veux que cette fonction n’appelle plus l’objet A mais l’objet B », et de propager cela dans le reste de mon application. On n’a plus besoin d’aller chercher à tous les endroits pour remplacer le code ou autre.
De même pour débugger, le fait d’avoir un objet qui contient toute les fonctionnalités permet de demander à cet objet-là de nous afficher tout ce qu’il y a dans le projet et si on peut réutiliser des fonctions déjà existantes. L’injection de dépendance facilite l’accès à ces fonctionnalités.
Est-ce qu’il y a eu de grosses évolutions sur la gestion des évènements ?
Effectivement, Drupal utilisait historiquement des Hooks, qui représentaient des points d’extensions, de la même manière qu’un évènement aujourd’hui. Pour enregistrer un hook, il fallait créer une fonction et lui dire « voici mes hooks à moi ». Ensuite Drupal s’occupait d’exploiter ces hooks et de les exposer aux autres modules. Ces hooks permettaient aux autres modules d’effectuer des opérations supplémentaires. Avec l’EventDispatcher de Symfony il n’y a plus besoin de ça.
Grâce à l’injection de dépendance, l’EventDispatcher est utilisable partout. Donc à n’importe quel moment dans le code on peut demander à l’EventDispatcher de « dispatcher » un événement. En une ligne, on peut créer un point d’extension dans le code et tous les modules tiers peuvent écouter cet événement là et rajouter du traitement.
C’est valable pour les modules mais également le core de Drupal, qui a une liste d’évènements pré-enregistrés.
Pour débugger et/ou lister les évènements présent dans l’application, il existe un composant tiers appelé Drupal Console, développé avec le composant Console de Symfony. Ce composant est très intéressant sur ce sujet-là. Comme pour le conteneur d’injection de dépendance, on peut demander à l’Event Dispacher de nous afficher tous les évènements disponibles dans l’application. Drupal Console est indispensable pour faire le pont entre Symfony et Drupal, d’un point de vue Déboggage, mais aussi de génération de code (Controllers, modules …).
Drush, l’outil historique en ligne de commande, est intégré à Drupal Console.
Quelle est la bonne approche pour un développeur Drupal pour avancer sur Drupal 8 avec Symfony ?
Il faut procéder par étape en abordant l’objet avant de monter sur Symfony. Pour les développeurs qui utilisaient Drupal 7 cela n’est pas forcément évident. Faire du CMS est évidemment différent que d’utiliser l’objet et cela peut amener à des complications.
Les concepts d’injections de dépendance, de Routing, de Controlleurs, d’Event Dispatcher etc. sont des concepts modernes qu’il faut connaitre avant de commencer à développer dans Drupal 8.
Pour cela une formation complète à Symfony me semble essentielle, avant de commencer à aborder Drupal 8. Ensuite on peut envisager une formation spécifique à Drupal 8 ou bien en utilisant tout simplement intensivement la documentation de Drupal ainsi que celle de Symfony.
