Quand envoyer des événements dans un module personnalisé?

Il s'agit d'une question concernant Magento 1 et Magento 2.

Je comprends que, comme bonne pratique, les développeurs de modules tiers sont encouragés à envoyer des événements dans leur module personnalisé pour faciliter le travail avec d'autres modules.

J'aimerais savoir:

• où un développeur doit-il envoyer des événements dans un module personnalisé?
• Y a-t-il un endroit recommandé pour envoyer des événements? Par exemple, contrôleurs, modèles, blocs, aides, observateurs?
• comment la répartition des événements affecte les performances?

Vous n'allez pas trouver ici une bonne réponse, claire et déterministe. Dans l'ensemble, vous devez répartir les événements dans votre module là où vous et vos utilisateurs en avez besoin - si vous ne pouvez penser à aucun endroit où ils pourraient être nécessaires, vous n'avez pas besoin de les répartir. Magento lui-même émet tellement d'événements à tellement d'endroits différents (pré / post-dispatch du contrôleur, toute opération crud, etc.) que votre module enverra déjà un certain nombre d'événements utiles sans que vous ne fassiez rien.

Étant donné que cela n'est pas satisfaisant, vous souhaitez que votre module distribue un événement lorsqu'il y a une action que votre module entreprend et que vos utilisateurs pourraient vouloir ajouter, supprimer des éléments, modifier ou entreprendre une action distincte indépendante de l'action d'origine. Par exemple - Magento a un visitor_initévénement qui ne fait pas partie de sa suite standard d'événements générés automatiquement. Cet événement permet aux programmeurs de modifier l'objet visiteur avant que Magento n'enregistre les données. Ceux - ci était aucune façon les développeurs de modules originaux déterministe saventc'est là qu'un événement devait être ajouté - il provenait probablement de demandes de fonctionnalités et / ou d'entretiens avec les utilisateurs du système. Sachez ce que vos utilisateurs veulent, et s'il n'est pas possible / pratique de créer une interface utilisateur / interface utilisateur pour les laisser le faire via l'administrateur, ajoutez un crochet d'événement afin qu'un autre programmeur puisse le faire pour eux.

Moins sexy, l'ajout d'événements peut également être un moyen peu coûteux pour permettre aux développeurs (soit vos utilisateurs, soit même votre équipe) d'ajouter des fonctionnalités dans un morceau de code noueux que tout le monde a peur de toucher. Plop votre dispatchEventappel au milieu du code, accrochez-vous, et vous pouvez ajouter votre fonctionnalité sans perturber le code dans la portée d'origine. [Éditeur: Vous devriez également refactoriser ce code horrible à un moment donné]

En termes de performances, l'ajout d'un événement à distribuer dépend de l'endroit où vous l'ajoutez. Lorsque vous appelez un dispatchévénement, Magento doit effectuer quelques appels PHP supplémentaires, interroger la configuration pour tous les observateurs configurés, puis appeler les observateurs. Fait une fois, il s'agit d'un ajout bon marché dans le cadre d'une expédition Magento standard. Cependant, fait à plusieurs reprises (par exemple, avant chaque rendu de bloc), cela peut s'additionner. Il n'y a pas de bonne règle empirique ici - comme toujours, la bonne réponse est le profil.

Enfin, avec Magento 2 w / r / t, il est encore trop tôt pour le dire. Tout ce qui précède s'applique toujours - cependant le système de plug-in ajoute quelques rides. Les plugins sont, d'un point de vue, un moyen de créer un comportement de type événement pour tout appel de méthode publique dans Magento. En théorie, si vous concevez correctement vos classes, vous ne devriez jamais avoir besoin d'un événement. Cependant, dans la pratique, déposer un événement dans un peu de code de méthode protégé ou privé sera une solution tentante pour les développeurs de Magento lorsque l'alternative est un long processus de refactoring. De plus, la création d'un événement spécifiquement nommé peut souvent créer une expérience plus conviviale pour les développeurs utilisant votre module.

J'espère que cela pourra aider!

Pour Magento 1, les bons moments pour lancer des événements sont avant et après toutes les opérations CRUD et avant et après le rendu. Beaucoup de ceux-ci sont déjà fournis par les classes abstraites dans le noyau, donc en pratique pas beaucoup d'événements tiers sont nécessaires.

Avec Magento 2, la situation est différente. Étant donné que les appels de méthode publique peuvent être interceptés avec des plug-ins, les événements personnalisés ne sont plus nécessaires.
Lors de la conception de classes, au lieu de simplement rendre publique chaque méthode afin qu'elle puisse être interceptée, il est préférable de décomposer une grande classe en plusieurs classes plus petites.
Chacune des petites classes pourrait alors avoir une ou deux méthodes publiques bien nommées et interceptables.

Comme l'a dit Vinai, avant / après les opérations CRUD. Un autre endroit important pour distribuer des événements est dans les blocs de formulaire adminhtml (le cas échéant). De cette façon, vous pouvez ajouter de nouveaux champs d'entrée si vous avez ajouté des attributs / champs personnalisés sans avoir à réécrire les blocs du formulaire d'administration. (C'est pour Magento 1). Voir l'exemple

Dans Magento 1, vous pouvez tirer parti des événements via les événements déclenchés automatiquement. Il vous suffit de définir une $_eventPrefixet des $_eventObjectpropriétés sur vos modèles. En outre, vous avez automatiquement déclenché des événements de contrôleur via les événements 'controller_action_predispatch_ ' . $this->getFullActionName()et 'controller_action_postdispatch_' . $this->getFullActionName()sur le contrôleur. Celles-ci peuvent vous aider presque partout.

Pour Magento 2, gardez vos méthodes publiques dans vos classes. Cela permet aux plugins d'intercepter vos méthodes. Si vous suivez cela, vous n'aurez pas à créer d'événements personnalisés.

J'espère que ça aide!