C'est la manière "historique" d'émettre un évènement.

L'objet jEvent sert à la fois d'émetteur d'événement, et en même temps de conteneur des réponses.

Pour émettre un événement, il faut utiliser la méthode statique notify().

Elle accepte en paramètre un nom d'évènement (qui n'est constitué que de caractères alphanumériques), et un tableau facultatif de paramètres (à utiliser selon l'évènement).

Vous recevez en retour l'objet jEvent instancié pour l'occasion, et contenant les réponses (ne pas confondre avec les objets jResponse, utilisés dans les contrôleurs). Les réponses sont un ensemble de valeurs dont la structure et le nombre dépend de l'événement et du nombre de modules ayant répondu.

   //exemple avec paramètre
   $eventParams = array('user' => $userObject);
   $theEvent = jEvent::notify('authCanLogin', $eventParams);
 
   //exemple sans paramètres
   $theEvent = jEvent::notify('authCanLogin2');

Pour accéder aux données des réponses retournés par les listeners des modules, il faut utiliser la méthode getResponse de l'objet jEvent qui a été retourné par notify:

  $reponses = $theEvent->getResponse();

Le résultat est un tableau des données que chaque module à renvoyé.

Vous avez d'autres méthodes pour manipuler les données retournées :

• inResponse($responseKey, $value) : indique si il existe une clé avec la valeur donnée dans les données retournées.
• getResponseByKey($responseKey) : renvoi la liste des données qui correspondent à la clé donnée (renvoi null si il n'y a aucune donnée avec cette clé)
• allResponsesByKeyAreTrue($responseKey) : indique si toutes les données avec la clé donnée ont la valeur true.
• allResponsesByKeyAreFalse($responseKey) : indique si toutes les données avec la clé donnée ont la valeur false.

Depuis Jelix 1.8, il est possible d'émettre des évènements sous forme d'objet que l'on instancie soit-même, et on le passe au distributeur.

L'avantage par rapport à la méthode classique des évènements nommés, est que l'on peut utiliser n'importe quel objet, avec des méthodes ou propriétés que les listeners peuvent appeler pour indiquer leur réponse, de manière plus spécifique que les méthodes getParam() ou add() de jEvent. On peut aussi continuer à utiliser un objet jEvent comme objet évènement.

L'objet représentant l'évènement doit implémenter l'interface Jelix\Event\EventInterface qui propose la méthode getName(). Cela permet d'indiquer un nom d'évènement particulier.

L'objet peut aussi implémenter l'interface Psr\EventDispatcher\StoppableEventInterface permettant à un listener de stopper la propagation de l'évènement aux listeners suivants.

Une fois l'objet évènement instancié, on le passe au distributeur. Celui-ci est donnée par la méthode Jelix\Core\Services::eventDispatcher(). Il implémente l'interface Psr\EventDispatcher\EventDispatcherInterface de la spécification PSR-14.

Exemple :

class \MyProject\MyEvent implements \Jelix\Event\EventInterface {
    protected $isOk = false;

    public function getName() {
        return 'thisIsMyEvent';
    }

    public function itsOk()
    {
        $this->isOk = true;
    }

    public function isItOk()
    {
        return $this->isOk;
    }
}

// creation de l'évènement
$event = new \MyProject\MyEvent();

// envoi de l'évènement aux listeners, qui peuvent par exemple appeler la
// méthode itsOk()
Jelix\Core\Services::eventDispatcher()->dispatch($event);

// on regarde ce qu'on répondu les listeners
if ($event->isItOk()) {
    //...
}

Il n'y a pas de listener par défaut dans les modules. Aussi, pour qu'un module puisse répondre à un événement, il faut créer un listener, et le déclarer dans le fichier events.xml du module. Il n'y a pas de limite du nombre de listener.

Il y a deux choses à faire pour un listener : le créer, puis le déclarer.

Créer le listener ¶

class authListener extends jEventListener {
// ou
// class \MyModule\Listeners\Auth extends \jEventListener {

   function onAuthCanLogin ($event) {

        // recupération d'un paramètre de l'événment
        $user = $event->getParam('user');

        // traitement
        $ok = true;
        if (isset($user->actif)) {
            $ok = ($user->actif == '1');
        }

        $ok = $ok && ($user->password != '');

        // renvoi de donnée en réponse
        $event->add(array('canlogin'=>$ok));
   }
}

class authListener extends jEventListener {

    protected $eventMapping = array(
      'foo.bar' => 'execFooBar'
    );

    function execFooBar (\jEvent $event) {
        // here process the event.
    }
}

Déclarer le listener ¶

<events xmlns="http://jelix.org/ns/events/1.0">
   <listener name="auth">
       <event name="AuthCanLogin" />
   </listener>
   <!-- or -->
   <listener name="\MyModule\Listeners\Auth">
       <event name="AuthCanLogin" />
       <event name="thisIsMyEvent" />
   </listener>
</events>

Il peut arriver que vous vouliez désactiver un listener fourni par un module tiers, pour un tas de raison.

Cela est possible en les indiquant dans la section [disabledListeners] de la configuration principale. Les clés sont les noms d'évènements, les valeurs sont les sélecteurs des listeners ou le nom complet de la classe du sélecteur si elle est autochargeable.

[disabledListeners]
authLogin="aModule~theListener"

Dans cet example, le listener theListener du module "aModule" ne sera pas appelé quand l'évènement authLogin sera émis.

Si vous voulez désactiver plusieurs listener pour un même évènement, utilisez simplement la notation [] pour indiquer un tableau :

[disabledListeners]
authLogin[]="aModule~theListener"
authLogin[]="\MyModule\Listeners\Auth"