php - example - magento 2 create events
Magento: ¿Cómo se desactiva o cambia cómo funciona un método de observación central? (4)
Me he estado preguntando sobre esto por un tiempo. ¿Qué pasa si Magento ha escrito una clase principal de Observer y realiza una funcionalidad que no desea que se ejecute, o si desea volver a escribirla? ¿Hay alguna manera de decir que no uses este método en un Observer? Solo usa el mío. Si configuro un método para mi propio Observer, ¿no hará primero la funcionalidad central y luego todo lo que tengo implementado?
Por ejemplo, Magento quiere guardar algunos datos en la base de datos en un método Observer, pero no quiero que guarde esos datos en absoluto, quiero que guarde algunos otros datos que he agregado columnas o atributos a la base de datos para .
Quería agregar un comentario a la respuesta de Alan @ porque creo que lo ha entendido, pero mi comentario fue demasiado largo y no tuve suficiente formato. Aquí va:
Bonito @Alan, una manera ingeniosa de arreglar lo que parece ser un hoyo respetando la arquitectura. Un par de pensamientos:
Si un módulo personalizado se une al mismo evento, el Observer personalizado se llamaría más tarde en la Cadena de Responsabilidad que el núcleo y, por lo tanto, podría anular el Observador principal. Esto depende de lo que esté haciendo el Observer principal, por ejemplo, establecer un valor de redirección. En el ejemplo proporcionado por OP, esto funcionará. Al vincularse a un evento Model_save_before, se llamará al Observer principal, pero su Observer aún puede modificar el contenido de los datos guardados del modelo antes de que se escriba en la base de datos. Puede cambiar o deshacer los valores que se ven afectados por el Observer principal.
para anular el modelo del Observador central, insertar un
<models><widget><rewrite>
en el config.xml sería el enfoque correctoeste podría ser uno de los pocos casos en los que no se requiere llamar a los
parent::
anulación (!)
HTH, JD
EDITAR : se agregó más información en el paso 1 para responder a los detalles de la pregunta de OP
La advertencia estándar sobre las anulaciones de clase es el último recurso para implementar su propia funcionalidad
Probablemente sea posible jugar con la configuración global de Magento para eliminar un Magento Observer básico, pero no hay una forma admitida de hacerlo.
Sin embargo, considere cómo se configuran los observadores Core.
<adminhtml>
<events>
<cms_wysiwyg_config_prepare>
<observers>
<widget_observer>
<class>widget/observer</class>
<method>prepareWidgetsPluginConfig</method>
</widget_observer>
</observers>
</cms_wysiwyg_config_prepare>
</events>
</adminhtml>
Los observadores son clases de modelos de Magento. Si se ha configurado un modelo con la sintaxis basada en URI / ruta
<class>widget/observer</class>
a diferencia de un nombre de clase PHP completo
<class>Mage_Widget_Model_Observer</class>
puede crear una anulación para la clase Observer Model (igual que para cualquier otro Modelo). Si se ha utilizado un nombre de clase PHP, no tiene suerte. (Puede colocar un archivo local en local / Mage / Widget / Model / Observer.php si está dispuesto a asumir la responsabilidad del mantenimiento, pero no lo recomiendo)
Por lo tanto, para anular al observador anterior, lo haría
Cree un módulo personalizado que incluya una anulación para la clase Mage_Widget_Model_Observer.
En su clase de anulación, redeclare
prepareWidgetsPluginConfig
para hacer lo que desee O anule el método específico. Esto podría incluir un método vacío para eliminar por completo la funcionalidad.
Gracias Jonathan, superé a Observer con la sintaxis básica de overiding del modelo
<config>
<global>
<models>
<sales>
<rewrite>
<observer>PPI_Sales_Model_Observer</observer>
</rewrite>
</sales>
</models>
</global>
</config>
Funcionó bien
Un mejor método para hacer esto es simplemente volver a declarar la definición del observador en un archivo config.xml.
Por ejemplo, necesitaba desactivar el observador enterprise_persistent_cart que se declaró en el evento controller_action_layout_generate_blocks_after por el módulo Enterprise_Persistent .
La declaración en el archivo config.xml de Enterprise_Persistent es tal
<frontend>
<events>
<controller_action_layout_generate_blocks_after>
<observers>
<enterprise_persistent_cart>
<class>enterprise_persistent/observer</class>
<method>removeCartLink</method>
</enterprise_persistent_cart>
</observers>
</controller_action_layout_generate_blocks_after>
Así que creé un módulo, y en el config.xml de mi módulo, hice lo siguiente:
<frontend>
<events>
<controller_action_layout_generate_blocks_after>
<observers>
<enterprise_persistent_cart>
<type>disabled</type>
</enterprise_persistent_cart>
</observers>
</controller_action_layout_generate_blocks_after>
También hice que mi módulo dependiera del módulo Enterprise_Persistent. Esto es necesario para garantizar que el archivo config.xml de mi módulo se procese DESPUÉS del archivo config.xml del módulo Enterprise_Persistent. Hice esto haciendo lo siguiente en el archivo de declaración de módulo de mi aplicación / etc / modules My_Module.xml de mi módulo
<config>
<modules>
<Atlex_AddCartLinkToHeader>
<active>true</active>
<codePool>local</codePool>
<depends>
<Enterprise_Persistent/>
</depends>
</Atlex_AddCartLinkToHeader>
</modules>
</config>
Para cada evento, solo puede haber una acción de observador declarada para un nombre de observador determinado. Por lo tanto, siempre que el archivo config.xml de mi módulo se procese después del archivo config.xml del módulo Enterprise_Persistent, mi declaración del observador para enterprise_persistent_cart será la acción del observador que se excute.
El nodo < type > disabled < / type > inhabilitará la activación del observador. Si quisiera anular al observador para ejecutar su propio método, simplemente debería reemplazar el nodo < tipo > con los nodos < clase > y < método > del observador.
Esto le permite anular / deshabilitar observadores sin anular las clases principales. Es más extensible para futuros desarrolladores.