> Gestion_d_evenements
fr

Présentation

Copix vous permet de profiter d'un système d'évènements afin de réaliser un couplage dit "souple" entre vos modules.

Ce système d'évènement permet, en une ligne, de faire en sorte que votre module prévienne tous les autres modules installés qu'il a réalisé une action (ajouté un contenu, supprimé un contenu, a mis à jour les droits, ...) afin que d'autres puissent avoir le choix d'y répondre.

C'est un système de couplage "souple" car il ne lie pas physiquement les modules concernés entre eux et permet à chacun de s'exécuter indépendamment les uns des autres.

Ce système d'évènement peut être intéressant lorsque vous développez des modules à fort caractère réutilisable (un moteur de recherche, un flux RSS pour indiquer les changements de votre site, un système de notification par mail, ...)

Différences entre couplage fort / couplage souple

Présentation du problème

Vous disposez d'un module de nouvelles.

Vous souhaitez que votre module de nouvelles ajoute ses publications au moteur de recherche. Aujourd'hui, vous avez développé un module de moteur de recherche nommé mysearch.

Code de la publication de nouvelle :


function processAddNews (){
    //.... tout le code de validation est effectué avant

    //insertion de la nouvelle
   _ioDAO ('nouvelle')->insert ($recordNouvelle);

   return _arRedirect ('nouvelle|admin|');
}
 

Couplage fort, sans évènement

Avec un couplage fort, inutile de se poser trop de question, le réflexe est de procéder ainsi :

Implémentation


function processAddNews (){
    //.... tout le code de validation est effectué avant

    //insertion de la nouvelle
   _ioDAO ('nouvelle')->insert ($recordNouvelle);

   //On ajoute la nouvelle au moteur de recherche
   _ioClass ('mysearch|index')->add ($recordNouvelle->titre, $recordNouvelle->contenu);

   return _arRedirect ('nouvelle|admin|');
}
 

Ici, clairement, on appelle en dur la classe d'indexation de notre moteur de recherche, et on suppose que notre module "nouvelle" soit parfaitement au fait de l'API de ce dernier.

Inconvénients

Et encore, ce n'est ici que la face visible du problème, car aujourd'hui cela ne concerne qu'un moteur de recherche.

Le coeur du problème, là où les choses se complexifient de façon exponentielle, c'est lorsqu'en plus d'un moteur de recherche nous souhaitons réaliser d'autres éléments (notifier de la publication d'une nouvelle, envoyer un mail pour une newsletter, ajouter le contenu aux nouveaux contenus du site, ...)

Le tout va faire que notre module sera ancré dans ses dépendances, et au final notre module qui devait être réutilisable ne le sera presque pas, ou en tout cas pas de façon "unitaire".

Couplage faible

C'est la que le système d'évènement rentre en jeu. Plutôt que d'appeler directement les classes d'un module, vous allez vous contenter d'indiquer à qui veut bien l'entendre que vous avez ajouté un contenu.

Implémentation


function processAddNews (){
    //.... tout le code de validation est effectué avant

    //insertion de la nouvelle
   _ioDAO ('nouvelle')->insert ($recordNouvelle);

   //on lance l'évènement
   _notify ('PublishedContent', array ('title'=>$recordNouvelle->titre,
                                       'content'=>$recordNouvelle->content));

   return _arRedirect ('nouvelle|admin|');
}
 

Conséquence

Ici on voit clairement qu'aucune API ou aucune dépendance n'est rajoutée à notre module de nouvelle, mais que ce dernier est ouvert au dialogue avec quiconque le souhaitera.

L'inconvénient majeur sera qu'il vous sera nécessaire de développer un Listener qui servira de pont entre l'interface de l'évènement et l'API de la recherche elle-même.

C'est donc un processus de développement un peu plus long, mais pour une souplesse plus grande.

Utilisé à bon escient, le système d'évènement vous permet de développer des modules capables de s'intégrer dans un ensemble cohérent et ouvert au dialogue.