Kiedy wysyłać zdarzenia w niestandardowym module?

To pytanie dotyczy zarówno Magento 1, jak i Magento 2.

Rozumiem, że zgodnie z dobrą praktyką programiści zewnętrzni są zachęcani do wysyłania zdarzeń w swoim niestandardowym module, aby ułatwić pracę z innymi modułami.

Chciałbym wiedzieć:

• gdzie deweloper powinien wysyłać zdarzenia w niestandardowym module?
• czy jest jakieś zalecane miejsce do wysłania wydarzeń? Np. Kontrolery, modele, bloki, pomocnicy, obserwatorzy?
• jak zdarzenia wysyłające wpływają na wydajność?

Nie znajdziesz tutaj dobrej, jasnej, deterministycznej odpowiedzi. Ogólnie rzecz biorąc, powinieneś wywoływać zdarzenia w module, w których Ty i Twoi użytkownicy ich potrzebujesz - jeśli nie możesz wymyślić, gdzie mogą być potrzebne, nie musisz ich wysyłać. Sam Magento emituje tak wiele zdarzeń w tak wielu różnych miejscach (wysyłanie kontrolera przed / po wysyłce, jakakolwiek operacja crud, itp.), Że moduł już wywoła wiele przydatnych zdarzeń bez twojej pomocy.

Ponieważ jest to niezadowalające, chcesz, aby moduł wywoływał zdarzenie, gdy moduł podejmie jakieś działania, do których użytkownicy mogą chcieć dodawać elementy, usuwać elementy, zmieniać lub podejmować osobne działanie niezależnie od działania pierwotnego. Na przykład - Magento ma visitor_initzdarzenie, które nie jest częścią standardowego zestawu zdarzeń generowanych automatycznie. To wydarzenie pozwala programistom zmodyfikować objet użytkownika, zanim Magento zarejestruje dane. To nie był sposób, w jaki oryginalni twórcy modułów poznali deterministyczniew tym miejscu trzeba było dodać wydarzenie - prawdopodobnie pochodziło ono z zaproszeń do funkcji i / lub wywiadów z użytkownikami systemu. Wiedz, czego chcą Twoi użytkownicy, a jeśli nie jest możliwe / praktyczne zbudowanie interfejsu użytkownika / UX, aby umożliwić im to za pośrednictwem administratora, dodaj hak zdarzeń, aby inny programista mógł to dla nich zrobić.

Mniej seksownie, dodawanie zdarzeń może być również tani sposób, aby umożliwić programistom (zarówno użytkowników, a nawet swój zespół), aby dodać niektóre funkcje w gnarly kawałka kodu, który każdy boi się dotknąć. Umieść swoje dispatchEventpołączenie w środku kodu, zaczep go i możesz dodać swoją funkcjonalność bez zakłócania kodu w oryginalnym zakresie. [Redaktor: W pewnym momencie powinieneś zreformować ten okropny kod]

Pod względem wydajności dodanie zdarzenia do wysyłki będzie zależeć od miejsca, w którym je dodasz. Kiedy wywołujesz dispatchzdarzenie, Magento musi wykonać kilka dodatkowych wywołań PHP, zapytać o konfigurację dla dowolnego skonfigurowanego obserwatora, a następnie wywołać obserwatora. Zrobione raz, jest to tani dodatek w ramach standardowej wysyłki Magento. Jednak powtarzane wielokrotnie (powiedzmy przed renderowaniem każdego bloku) może się to sumować. Nie ma tu żadnej dobrej zasady - jak zawsze właściwą odpowiedzią jest profil.

Wreszcie, w / r / t Magento 2, jest jeszcze za wcześnie, aby powiedzieć. Wszystko powyższe nadal obowiązuje - jednak system wtyczek dodaje kilka zmarszczek. Wtyczki są, z jednego punktu widzenia, sposobem tworzenia zdarzeń podobnych do zachowań dla dowolnego publicznego wywołania metody w Magento. Teoretycznie, jeśli poprawnie projektujesz swoje zajęcia, nie powinieneś nigdy potrzebować wydarzenia. Jednak w praktyce upuszczenie zdarzenia w nieco chronionym lub prywatnym kodzie metody będzie kuszącym rozwiązaniem dla programistów Magento, gdy alternatywą jest długi proces refaktoryzacji. Ponadto utworzenie wydarzenia o określonej nazwie może często stworzyć bardziej przyjazne środowisko dla programistów korzystających z tego modułu.

Mam nadzieję, że to pomaga!

W przypadku Magento 1 dobre czasy do rzucania zdarzeniami są przed i po wszystkich operacjach CRUD oraz przed i po renderowaniu. Wiele z nich jest już zapewnionych przez klasy abstrakcyjne w rdzeniu, więc w praktyce nie jest potrzebnych wiele wydarzeń stron trzecich.

Z Magento 2 sytuacja jest inna. Ponieważ publiczne wywołania metod można przechwytywać za pomocą wtyczek, zdarzenia niestandardowe nie są już potrzebne.
Projektując klasy, zamiast po prostu upubliczniać każdą metodę, aby można ją było przechwycić, lepiej jest rozłożyć dużą klasę na wiele mniejszych klas.
Każda z mniejszych klas może wtedy mieć jedną lub dwie ładnie nazwane i możliwe do przechwycenia metody publiczne.

Jak powiedział Vinai, przed / po operacjach CRUD. Innym ważnym miejscem do wysyłania zdarzeń są bloki formularzy adminhtml (jeśli dotyczy). W ten sposób możesz dodawać nowe pola wejściowe, jeśli dodałeś niestandardowe atrybuty / pola bez konieczności przepisywania bloków formularza administratora. (To dotyczy Magento 1). Patrz przykład

W Magento 1 możesz wykorzystywać zdarzenia poprzez zdarzenia, które są automatycznie odpalane. Wszystko, co musisz zrobić, to ustawić $_eventPrefixi $_eventObjectwłaściwości na swoich modelach. Ponadto masz automatycznie uruchamiane niestandardowe zdarzenia kontrolera poprzez zdarzenia 'controller_action_predispatch_ ' . $this->getFullActionName()i 'controller_action_postdispatch_' . $this->getFullActionName()na kontrolerze. Mogą cię tam dotrzeć przez większość drogi.

W przypadku Magento 2, upublicznij swoje metody w swoich klasach. Dzięki temu wtyczki przechwytują twoje metody. Jeśli to zrobisz, nie będziesz musiał tworzyć żadnych niestandardowych zdarzeń.

Mam nadzieję, że to pomoże!