Wydarzenia Magento Observer - kolejność operacji

9

Próbuję wprowadzić funkcjonalność do catalog_model_product_duplicatewydarzenia. Częścią tego modułu będzie zapewnienie, że stan magazynowy duplikowanego produktu również zostanie zduplikowany; obecnie tak nie jest.

Widzę, że CatalogInventoryobserwuje to zdarzenie i konfiguruje pewne standardowe informacje giełdowe. Czy mogę zagwarantować, że kluczowe wydarzenia zostaną rozwiązane przed moimi lokalnymi mieszkańcami? Czy jest tu jakaś kolejność operacji, na której mogę polegać?

philwinkle
źródło

Odpowiedzi:

11

Kolejność wysyłania zdarzeń zależy od kolejności, w jakiej moduły są ładowane. Ponieważ musisz mieć pewność, że CatalogInventoryobserwatorzy modułu odpalą, zanim zrobi to twój, musisz po prostu skonfigurować moduł, aby był zależny od Mage_CatalogInventorymodułu. Możesz to zrobić, dodając węzeł zależny do kodu w app/etc/modules/My_Module.xmlpliku:

<config>
    <modules>
        <My_Module>
            <active>true</active>
            <codePool>local</codePool>
            <depends>
                <Mage_CatalogInventory />
            </depends>
        </My_Module>
    </modules>
</config>

dependsWęzeł w powyższym XML jest kluczowy element konfiguracji tutaj, ponieważ zmusza rdzenia modułu Magento, aby załadować przed swoje robi.

davidalger
źródło
7

Kolejność wysyłania zdarzeń nie może być łatwo zagwarantowana. Są one zależne od kolejności ładowania modułów. Zazwyczaj wszyscy obserwatorzy zdarzeń kluczowych będą wywoływani przed obserwatorami społeczności i lokalnej puli kodów.

Istnieje metoda zmuszenia obserwatorów magento do strzelania po niestandardowym przez „udawanie” zależności modułu podstawowego od lokalnego lub społecznościowego. Spójrz na odpowiedź Lee tutaj: zrób niestandardowego obserwatora ostrzałem przed istniejącym obserwatorem Magento .

/app/etc/modules/Groupname_Page.xml

<config>
    <modules>
        <Groupname_Page>
            <active>true</active>
            <codePool>local</codePool>
            <depends>
                <!-- Your dependencies go here -->
            </depends>
        </Groupname_Page>
        <Enterprise_PageCache>
            <depends>
                <Groupname_Page />
            </depends>
        </Enterprise_PageCache>
    </modules>
</config>

Osobiście nie podoba mi się takie podejście, ponieważ nie wiem, jakie byłyby konsekwencje wymuszania tej zależności.

W twoim przypadku wydaje się, że powinieneś wykonać jakieś wykrywanie danych / stanu, aby wiedzieć, czy został zwolniony, czy nie. Lepsze byłoby sprawdzenie danych / stanu w modelu niż próba wymuszenia kolejności zdarzeń.

beeplogic
źródło
W moim przypadku nie mam jednak nic do roboty, jeśli towar na magazynie jeszcze nie istnieje. Masz jakieś przemyślenia na temat późniejszego zdarzenia, które mógłbym powąchać, aby sprawdzić, czy było to wynikiem powielonej metody?
philwinkle
5

Ogólna odpowiedź

Obserwatory są wykonywane najpierw według obszaru , a następnie według kolejności ładowania modułów

Oznacza to, że wszyscy zarejestrowani obserwatorzy <global>są wykonywani przed wszystkimi obserwatorami zarejestrowanymi w <frontend>lub <adminhtml>.

W obrębie obszaru obserwatory są wykonywane w kolejności, w jakiej pojawiają się w połączonym drzewie konfiguracji XML, co oznacza technicznie w kolejności załadowania modułów.

Kolejność ładowania modułu jest ustalana w następujący sposób:

  1. Wykres zależności jest zbudowany na podstawie <depends>definicji w app/etc/modules/*.xml. Jeśli X zależy od Y, Y jest ładowane przed X.

  2. Po zamówieniu według zależności moduły podstawowe mają pierwszeństwo przed modułami społecznościowymi i lokalnymi

  3. Cała reszta jest ładowana alfabetycznie. Zauważ, że nazwa pliku app/etc/modulessłuży do porównania, a nie rzeczywista nazwa modułu.

Masz więc dwie opcje wpływu na kolejność ładowania modułu:

  1. polegać na innym module, aby po jego wykonaniu obserwatorzy byli wykonywani (lub sprawić, aby drugi moduł był zależny od twojego, aby mieć je wcześniej wykonane)
  2. Zmień nazwę pliku definicji modułu. Nie musisz zmieniać nazwy samego modułu, ponieważ nazwa pliku nie ma znaczenia poza kolejnością ładowania.

(„3. dodaj swój moduł do podstawowej puli kodów” nie ma znaczenia)

Zobacz też:

Fabian Schmengler
źródło
1

Tylko sugestia, obserwuj jedno catalog_model_product_duplicatei drugie catalog_model_product_save_afterz obserwatorem singletonów. W catalog_model_product_duplicateustawieniach danych inwentarza jako danych obserwatora oraz w catalog_model_product_save_afterużyciu tych danych do zapełnienia inwentarza dla zduplikowanego produktu.

Petar Dzhambazov
źródło
Sugerujesz więc zapisanie właściwości do obiektu, który został mi przekazany w wydarzeniu, a następnie przetestowanie tego na catalog_model_product_save_after..., który mógłby działać. Jedyną pułapką byłoby przetrwanie nieruchomości bez wzywania save()... żadnych myśli?
philwinkle
Będziesz zapisywać model zapasów, a nie produkt, więc nie powinieneś zapętlać się.
Petar Dzhambazov