Événements Symfony : kernel.request et événements de l'application

Événements Symfony : le noyau, Doctrine ou l'application annoncent ce qui arrive, et des écouteurs y réagissent sans que l'émetteur les connaisse.

// Dans le contrôleur, une fois le plat enregistré :
$dispatcher->dispatch(new PlatAjoute($plat, $employe));

#[AsEventListener] // l'événement écouté est déduit du type : App\Event\PlatAjoute
final class InviterLesGuildes
{
    public function __invoke(PlatAjoute $event): void { /* inviter chaque guilde */ }
}

#[AsEventListener] // priorité 0 : après le routeur (32), la route est connue
final class FermeLeLundi
{
    public function __invoke(RequestEvent $event): void { /* $event->setResponse(…) */ }
}

Le noyau émet kernel.request, kernel.controller, kernel.response ou kernel.exception à chaque requête ; Doctrine émet prePersist ou postUpdate autour des écritures ; l'application émet les siens, de simples objets passés à EventDispatcherInterface::dispatch(). Les pièges ne lèvent aucune erreur : un écouteur de priorité supérieure à 32 passe avant le routeur et ne connaît pas encore la route ; un événement dispatché sous un nom explicite, dispatch($event, 'plat.ajoute'), n'atteint plus ceux qui écoutent le nom de sa classe. debug:event-dispatcher montre qui écoute quoi, et dans quel ordre.

Les exercices font réparer une taverne où chaque morceau fonctionne mais rien n'arrive au bon moment : une fermeture du lundi ignorée, un plat ajouté dont personne n'est prévenu, des slugs choisis à la main réécrits par un écouteur Doctrine. Côté Laravel, un exercice fait traiter avec #[DebounceFor] le seul dernier événement d'une rafale.