Magento Observer Events - ordine delle operazioni


9

Sto tentando di iniettare funzionalità catalog_model_product_duplicatenell'evento. Parte di questo modulo sarà garantire che anche lo stato delle scorte del prodotto duplicato sia duplicato; attualmente non lo è.

Vedo che CatalogInventoryosserva questo evento e imposta alcune informazioni standard di borsa. Posso essere certo che gli eventi chiave vengano risolti prima dei miei locali? Esiste un ordine delle operazioni su cui posso contare?

Risposte:


11

L'ordine in cui vengono inviati gli eventi dipende dall'ordine in cui vengono caricati i moduli. Dato che devi essere sicuro che gli CatalogInventoryosservatori del modulo si attivino prima del tuo, ciò che devi fare è semplicemente configurare il tuo modulo in modo che dipenda dal Mage_CatalogInventorymodulo. Puoi farlo aggiungendo un nodo dipendente al codice nel tuo app/etc/modules/My_Module.xmlfile:

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

Il dependsnodo nell'XML sopra è la parte cruciale della configurazione qui, in quanto forza il modulo principale di Magento a caricarsi prima del tuo.


7

L'ordine in cui vengono inviati gli eventi non può essere facilmente garantito. Dipendono dall'ordine in cui i moduli vengono caricati. In genere tutti gli osservatori di eventi core verranno chiamati prima degli osservatori di pool di codici locali e locali.

Esiste un metodo per forzare gli osservatori di magento a sparare dopo uno personalizzato "fingendo" una dipendenza di un modulo principale da uno locale o di comunità. Dai un'occhiata alla risposta di Lee qui: fai sparare un osservatore personalizzato davanti a un osservatore Magento esistente .

/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>

Personalmente non mi piace questo approccio in quanto non so quali conseguenze avrebbe forzare quella dipendenza.

Per il tuo caso d'uso, sembra che dovresti fare una sorta di rilevamento per dati / stato per sapere se è stato sparato o meno. Il controllo di uno stato / dati su un modello sarebbe preferibile rispetto al tentativo di forzare un ordine di eventi.


Nel mio caso, tuttavia, non ho nulla da fare se l'articolo in magazzino non esiste ancora. Qualche idea su un evento successivo che ho potuto annusare per vedere se era il risultato del metodo duplicato?
Filwinkle,

5

Una risposta generale

Gli osservatori vengono eseguiti prima per area , quindi per ordine di caricamento del modulo

Ciò significa che tutti gli osservatori registrati <global>vengono eseguiti prima che tutti gli osservatori registrati in <frontend>o <adminhtml>.

All'interno di un'area, gli osservatori vengono eseguiti nell'ordine in cui appaiono nell'albero XML di configurazione unito, il che significa tecnicamente nell'ordine in cui i moduli sono stati caricati.

L'ordine di caricamento del modulo è determinato come segue:

  1. Un grafico delle dipendenze viene creato dalle <depends>definizioni in app/etc/modules/*.xml. Se X dipende da Y, Y viene caricato prima di X.

  2. Dopo l'ordinamento per dipendenza, i moduli principali hanno la precedenza sui moduli locali e della comunità

  3. Tutto il resto viene caricato in ordine alfabetico. Si noti che il nome del file in app/etc/modulesviene utilizzato per il confronto, non il nome effettivo del modulo.

Quindi hai due opzioni per influenzare l'ordine di caricamento del modulo:

  1. dipende da un altro modulo per far eseguire i tuoi osservatori dopo di esso (o fai in modo che l'altro modulo dipenda dal tuo per averli eseguiti prima)
  2. Rinomina il file di definizione del modulo. Non è necessario rinominare il modulo stesso perché il nome del file non ha importanza se non per caricare l'ordine.

("3. aggiungi il tuo modulo al pool di codici core" non conta)

Guarda anche:


1

Solo un suggerimento, osserva entrambi catalog_model_product_duplicatee catalog_model_product_save_aftercon l'osservatore singleton. Nel catalog_model_product_duplicateimpostare i dati di inventario come dati di osservatore e catalog_model_product_save_afternell'uso di tali dati per popolare l'inventario per il prodotto duplicato.


Quindi stai suggerendo di salvare una proprietà sull'oggetto che mi è stato dato nell'evento, quindi testarlo su catalog_model_product_save_after... che potrebbe funzionare. L'unica trappola sarebbe persistere nella proprietà senza chiamare save()... qualche pensiero lì?
Filwinkle,

Salverai il modello di inventario, non il prodotto, quindi non dovresti essere sorpreso.
Petar Dzhambazov,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.