La notion d'événements est généralement absente de la conception d'application PHP, au moins au sens classique du terme, pour la simple raison que le langage n'offre pas de support natif de cette approche de la programmation. Si certains frameworks ou CMS, comme Drupal et ses hooks, en proposent leur propre implémentation, nous allons voir ici une ingénieuse librairie permettant d'étendre le principe à toute application.

Initialement pensée pour matérialiser ce qui constitue l'essence du framework Symfony 2, à savoir le découplage maximum des composants, la librairie sfEventDispatcher est librement inspirée d'un système équivalent au coeur des systèmes OS X d'Apple, le Cocoa Notification Center. En effet, l'échange de messages entre le système d'exploitation et les applications comme entre les applications elles-mêmes est le concept central autour duquel est bâtie l'architecture de MacOS X. L'idée simple à l'origine de sfEventDispatcher, c'est qu'à l'instar du système d'Apple, une application PHP est un microcosme dans lequel évoluent différents composants, qui sans nécessairement avoir conscience les uns des autres, ont besoin de communiquer entre eux pour constituer un workflow. La majorité des composants des applications modernes, même en PHP, sont représentés par des classes, dont les méthodes, lors de leur exécution, peuvent être assimilées à des « moments » du flux d'exécution. L'enchaînement des événements est orchestré en général par un composant central, ou frontal (vocable particulièrement usité dans un contexte MVC), qui décide qui fait quoi, et dans quel ordre, le tout en fonction de la requête de l'utilisateur. La gestion d'événements dans l'application peut, dans une certaine mesure, être mise en parallèle de ce processus, mais à l'échelle du composant. Fondamentalement, on permet aux méthodes d'informer les autres composants de ce qu'elles sont en train de faire, en leur donnant la possibilité de prendre la main le temps d'ajouter leurs propres traitements à ceux de la méthode appelante. La différence principale résidant bien sûr en ce que chaque méthode peut déclencher un ou plusieurs traitements, faisant ainsi prendre au workflow des chemins de traverse que ne saurait gérer un composant central, sous peine de la confusion la plus totale. Cette manière de fonctionner a de nombreuses qualités, dont la souplesse évolutive n'est pas la moindre. En effet, une fois un traitement implémenté, en fonction d'un cahier des charges précis, il est possible d'en modifier certains aspects, ou de les étendre, sans pour autant toucher au code initial, si ce n'est en ajoutant les deux lignes de code nécessaires à l'émission d'un événement. Autrement dit, on va pouvoir ajouter des fonctionnalités sans remettre en cause un code testé et validé. Le risque de régression est donc réduit drastiquement.

Gauthier Delamarre