Magento 1: ¿por qué algunos métodos de observación llaman a getEvent () y otros no?


8

Algo que noté recientemente y tengo curiosidad al respecto.

Ejemplo 1: el uso de getEvent()

En Mage_Core_Model_Localeel setLocale()método, se distribuye un evento:

Mage::dispatchEvent('core_locale_set_locale', array('locale'=>$this));

Un observador para este evento es bindLocale()deMage_Adminhtml_Model_Observer

public function bindLocale($observer)
{
    if ($locale=$observer->getEvent()->getLocale()) {
        if ($choosedLocale = Mage::getSingleton('adminhtml/session')->getLocale()) {
            $locale->setLocaleCode($choosedLocale);
        }
    }
    return $this;
}

Entonces, como puede ver, para recuperar la configuración regional, primero llamamos getEvent()al observador.

Ejemplo 2: sin getEvent()

En Mage_Wishlist_Block_Customer_Wishlist_Item_Optionsel __construct()método, se distribuye un evento:

Mage::dispatchEvent('product_option_renderer_init', array('block' => $this));

Por lo tanto, estamos de acuerdo en que se usa la misma sintaxis para los ejemplos 1 y 2.

Sin embargo, un observador para este segundo ejemplo es initOptionRenderer()deMage_Bundle_Model_Observer

public function initOptionRenderer(Varien_Event_Observer $observer)
{
    $block = $observer->getBlock();
    $block->addOptionsRenderCfg('bundle', 'bundle/catalog_product_configuration');
    return $this;
}

Y como puede ver, para recuperar el bloque, no llamamos getEvent()al observador

Pregunta

  • ¿Por qué se getEvent()llama al método en el ejemplo 1? ¿O por qué getEvent()no se llama en el ejemplo # 2?
  • ¿Cuál es el propósito del getEvent()método?
  • ¿Dónde se debe usar getEvent()y dónde no se debe usar?

Respuestas:


7

Probablemente tiene razones históricas, que van más allá de la versión 1.0.

El Varien_Eventobjeto es el lugar lógico para contener parámetros para un evento concreto, pero dado que Magento pasa un Varien_Observerobjeto a todos los métodos de observación, el acceso directo a los parámetros tiene sentido (y ha estado allí al menos desde 1.1).

En realidad, no veo ningún valor en dos objetos diferentes, ya que se usan hoy .

Pero obviamente no fue planeado así desde el principio. En el método Mage::addObserver(), no solo se establecen los nombres de eventos y observadores y los argumentos estáticos del <args>nodo XML, sino también una devolución de llamada:

$observer->setName($observerName)->addData($data)->setEventName($eventName)->setCallback($callback);

De esta manera, los observadores pueden despacharse, con $observer->dispatch($event). En ese caso, los observadores no tendrían los datos del evento en sí mismos y necesitaría que los utilizara getEvent()para acceder a ellos. Pero el método no se usa en ningún lado, por lo que en la práctica no importa.

Si desea practicar algo de arqueología de software y excavar más, encontrará más código muerto que sugiere ideas originales que nunca llegaron al producto final, como el Varien_Event_Observer_Collection.


Gracias. Iba a mencionar aspectos "históricos". Parece que hiciste eso por nosotros :)
Rajeev K Tomy

8

Una cosa está clara.

Llamar $observer->getEvent()->getSomething()y $observer->getSomething()devolver lo mismo.

Echa un vistazo al Mage_Core_Model_App::dispatchEventmétodo.

En un momento tienes $event = new Varien_Event($args);dónde $argsestán los argumentos pasados ​​al dispatchEventmétodo.
Y se Varien_Eventextiende Varien_Objectpara que pueda acceder mágicamente a los elementos $argsdesde la Varien_Eventinstancia.

pero también existe esta línea $observer->addData($args);donde $argsestán las mismas cosas que arriba.

Varien_Event_Observertambién se extiende Varien_Objectpara que esto le permita acceder mágicamente a los elementos a $argstravés del objeto Observador.

Conclusión:

El $_datamiembro en la clase Observador y en la clase Evento contiene el mismo tipo de cosas. El observador tiene además algunos otros campos. como event, event_name.

Digamos que se $argsve así:

array(
   'some_arg' => 'someArg',
   'other_arg' => 'otherArg',
)

Al despachar el evento, el $_dataobjeto en el evento se vería así:

array(
   'some_arg' => 'someArg',
   'other_arg' => 'otherArg',
   'name' => 'event name here'
)

y en la clase Observador se vería así:

array(
   'some_arg' => 'someArg',
   'other_arg' => 'otherArg',
   'event_name' => 'event name here',
   'event' => instance of Varien_event,
   'callback' => ..., 
   'name' => 'observer name here'
)

Pero no puedo responder por qué existe esta falta de coherencia.
Solo puedo especular que el código fue escrito por 2 desarrolladores diferentes.
Si vale algo, siempre lo uso $observer->getEvent()->getSomething().

[EDITAR]

¿Por qué se llama al método getEvent () en el ejemplo # 1? ¿O por qué no se llama a getEvent () en el ejemplo # 2?

Falta de coherencia

¿Cuál es el propósito del método getEvent ()?

El Varien_Eventobjeto debe ser un objeto envoltorio sobre los argumentos pasados ​​al observador

¿Dónde se debe usar getEvent () y dónde no se debe usar? Úsalos como quieras. Obtendrá el mismo resultado todo el tiempo.


Obtuve la explicación sobre la falta de coherencia, mira mi respuesta
Raphael en Digital Pianism

Siempre prefiero $observer->getEvent()tomar cualquier dato en observador. Sé que podemos obtener datos $observerdirectamente. Pero no hago eso porque siempre siento que la inyección de objetos Varien_Eventes muy específica para contener datos de eventos. Por lo tanto, siempre dependo del objeto de evento. Siento que ese es el enfoque correcto.
Rajeev K Tomy

@RajeevKTomy vea mi respuesta, en realidad no tiene sentido usarlo, getEvent()excepto si necesita el nombre del evento O desea ser compatible con Magento 1.0
Raphael en Digital Pianism

3

Explicación sobre la falta de consistencia.

Según Vinai y lo que Vitaly Korotun le dijo en algún momento:

getEvent()Es legado. De vuelta en Magento 1.0 días, los datos del evento no se pudieron extraer directamente del observador.

Entonces, si no necesita obtener event_namey no le importa demasiado que su código sea compatible con Magento 1.0, puede omitirlo getEvent().

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.