Filter by Category
Le but de cet article n’est pas d’expliquer le fonctionnement des événements symfony, la documentation officielle est très bien faite à ce sujet, et pas mal...
En ce moment nous sommes en train de travailler sur un site de collectionneurs et nous avons le plaisir de tomber sur quelques cas intéressants au niveau développement ce qui...
Aujourd’hui je vais vous montrer comment rendre des objets commentables grâce à un behavior Doctrine que j’ai créé, et le plugin qui permet de l’exploiter. Le...
sfDoctrineGuardPlugin comme son nom l’indique est la version Doctrine de sfGuardPlugin qui est THE plugin de gestion des utilisateurs de Symfony. Il comporte des formulaires...
-Comment faire pour filtrer l'affichage dans l'admin generator lorsqu'on a à faire à un champs qui n'est pas dans la table considérée ? Un exemple ici : j'ai des utilisateurs,...
On c'est rendu compte ici qu'il y avait pas mal de questions en rapport avec le schema.yml qui ressortaient régulièrement. Le schema.yml est généralement trop vite oublié....
Comment mettre en place un « Rich Text Editor » dans un backend Symfony 1.2 doctrine ? J’ai trouvé la solution dans un post du forum symfony, je vous donne la version...
Le but de cet article n’est pas d’expliquer le fonctionnement des événements symfony, la documentation officielle est très bien faite à ce sujet, et pas mal d’articles expliquant leur implementation existent déjà.
Le but est juste de savoir comment faire pour avoir accès à l’event dispatcher depuis les classes du modèle, de manière à pouvoir lever des événements « métiers » qui permettent des traitements qui se rapprochent des trigger sql. L’avantage est de rester au sein de l’application symfony et ne pas disperser la logique. C’est une problèmatique que nous avons rencontré à plusieurs reprises dans les projets et nous avons pu trouver cette implementation grace à n1k0 de chez Akei.
Comments
Y’a quand même de drôle de problème avec la coloration syntaxique du code dans ce billet, dommage :/
Sinon ravi d’avoir aidé/inspiré 🙂
Les couleurs sont maintenant ok. Je sais pas qui avait tout pété..
Je suis retourné voir la doc vu qu’il me semblait qu’il y avait un moyen simple d’accéder à l’event dispatcher depuis absolument partout, et ce qu’ils disent c’est:
$dispatcher = ProjectConfiguration::getActive()->getEventDispatcher();
permet de récupérer l’event dispatcher depuis n’importe où dans l’application.
Moi j’ai commencé à utiliser les évènements récemment, ma réaction serait plutôt, « mais pourquoi on n’a pas ça direct en standard dans le langage? ». Plutôt côté accros donc!
Avec ce système, vous mixez au sein du même projet le système d’événements de Doctrine et celui de Symfony.
Je suis bien placé pour savoir que ça peut provoquer de mauvaises surprises. J’ai utilisé cette technique sur un projet qui lançait/écoutait un grand nombre d’événements (https://freelancer-app.fr) et je m’en suis mordu les doigts.
Certains événements dépendaient du système de Doctrine et d’autres de celui de symfony. Je ne savais parfois plus qui lançait/écoutait quoi. Sur certains événements complexes, j’ai finis par me retrouver avec des problèmes liés à l’ordre d’appel des listeners et de synchronisation des objets en mémoire.
J’ai presque fini à un refactoring en profondeur de mon projet, la quasi-totalité de mes événements sont gérés par doctrine.
Je trouve que l’organisation du code s’en trouve bien mieux et qu’elle est au final plus logique: tous les événements qui modifient un composant du modèle sont gérés par les événements de Doctrine dont c’est quand même le boulot.
Les quelques événements symfony restants sont très marginaux, comme par exemple des alertes emails qui ne modifient pas en retour le modèle.