Quando enviar eventos em um módulo personalizado?

Esta é uma pergunta sobre o Magento 1 e o Magento 2.

Entendo que, como uma boa prática, os desenvolvedores de módulos de terceiros são incentivados a enviar eventos em seu módulo personalizado para facilitar o trabalho com outros módulos.

Eu gostaria de saber:

• onde um desenvolvedor deve enviar eventos em um módulo personalizado?
• existe algum local recomendado para despachar eventos? Por exemplo, controladores, modelos, blocos, ajudantes, observadores?
• como os eventos de despacho afetam o desempenho?

Você não encontrará uma resposta boa, clara e determinista aqui. Em geral, você deve despachar eventos em seu módulo onde você e seus usuários precisam deles - se você não consegue pensar em qualquer lugar em que possam ser necessários, não precisa despachá-los. O próprio Magento emite tantos eventos em tantos lugares diferentes (pré / pós-despacho do controlador, qualquer operação crud, etc.) que seu módulo já despachará vários eventos úteis sem que você faça nada.

Como isso é insatisfatório, você deseja que seu módulo envie um evento quando houver alguma ação em que seu módulo execute, para que os usuários possam adicionar itens, excluir itens, alterar ou executar uma ação separada, independentemente da ação original. Por exemplo - Magento tem um visitor_initevento que não faz parte de seu conjunto padrão de eventos gerados automaticamente. Este evento permite que os programadores modifiquem o objeto do visitante antes que o Magento registre os dados. Não foi assim que os desenvolvedores do módulo original sabem deterministicamentefoi aqui que um evento precisou ser adicionado - provavelmente veio de solicitações de recursos e / ou entrevistas com usuários do sistema. Saiba o que seus usuários desejam e, se não for possível / prático criar uma UI / UX para permitir que eles o façam pelo administrador, adicione um gancho de evento para que outro programador faça isso por eles.

Menos sexy, a adição de eventos também pode ser uma maneira barata de permitir que os desenvolvedores (seus usuários ou até sua equipe) adicionem alguma funcionalidade a um pedaço macabro de código que todos têm medo de tocar. Posicione sua dispatchEventchamada no meio do código, conecte-se a ela e você poderá adicionar sua funcionalidade sem perturbar o código no escopo original. [Editor: Além disso, você deve refatorar esse código horrível em algum momento]

Em termos de desempenho, a adição de um evento a ser despachado dependerá de onde você o adicionar. Quando você chama um dispatchevento, o Magento precisa fazer algumas chamadas PHP extras, consultar a configuração para qualquer observador configurado e, em seguida, chamar os observadores. Feito uma vez, esta é uma adição barata no escopo de uma expedição padrão do Magento. No entanto, feito repetidamente (digamos, antes de cada bloco renderizar), isso pode aumentar. Não existe uma boa regra geral aqui - como sempre, a resposta certa é o perfil.

Finalmente, com Magento 2, ainda é cedo para dizer. Todas as opções acima ainda se aplicam - no entanto, o sistema de plug-ins adiciona algumas rugas. Plugins são, de um ponto de vista, uma maneira de criar eventos como comportamento para qualquer chamada de método público no Magento. Em teoria, se você estiver projetando suas aulas corretamente, nunca precisará de um evento. No entanto, na prática, colocar um evento em um pouco de código de método protegido ou privado será uma solução tentadora para os desenvolvedores do Magento quando a alternativa for um longo processo de refatoração. Além disso, a criação de um evento nomeado especificamente pode criar uma experiência mais amigável para os desenvolvedores que usam seu módulo.

Espero que ajude!

Para o Magento 1, bons momentos para lançar eventos são antes e depois de todas as operações CRUD e antes e depois da renderização. Muitos deles já são fornecidos pelas classes abstratas no núcleo, portanto, na prática, não são necessários muitos eventos de terceiros.

Com o Magento 2 a situação é diferente. Como as chamadas de método público podem ser interceptadas com plug-ins, os eventos personalizados não são mais necessários.
Ao projetar classes, em vez de simplesmente tornar todos os métodos públicos, para que possam ser interceptados, é melhor decompor uma classe grande em várias classes menores.
Cada uma das classes menores pode ter um ou dois métodos públicos bem nomeados e interceptáveis.

Como Vinai disse, antes / depois das operações CRUD. Outro local importante para despachar eventos é em adminhtml blocos de formulário (se aplicável). Dessa forma, você pode adicionar novos campos de entrada se tiver adicionado atributos / campos personalizados sem precisar reescrever os blocos de formulário do administrador. (Isto é para o Magento 1). consultar exemplo

Dentro do Magento 1, você pode alavancar eventos através dos eventos disparados automaticamente que ocorrem. Tudo que você precisa fazer é definir as propriedades $_eventPrefixe $_eventObjectnos seus modelos. Além disso, você customizou os eventos do controlador através dos eventos 'controller_action_predispatch_ ' . $this->getFullActionName()e 'controller_action_postdispatch_' . $this->getFullActionName()no controlador automaticamente. Aqueles podem levar você a maior parte do caminho até lá.

Para o Magento 2, mantenha seus métodos públicos dentro de suas classes. Isso permite que os plugins interceptem seus métodos. Se você seguir isso, não precisará criar nenhum evento personalizado.

Eu espero que isso ajude!