8

Something I noticed recently and I'm curious about it.

Example 1: the use of getEvent()

In Mage_Core_Model_Locale in the setLocale() method, an event is dispatched:

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

An observer for this event is bindLocale() from Mage_Adminhtml_Model_Observer

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

So as you can see, to retrieve the locale, we first call getEvent() on the observer.

Example 2: without getEvent()

In Mage_Wishlist_Block_Customer_Wishlist_Item_Options in the __construct() method, an event is dispatched:

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

So we agree that the same syntax is used for example 1 and 2.

However, an observer for this second example is initOptionRenderer() from Mage_Bundle_Model_Observer

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

And as you can see, to retrieve the block, we don't call getEvent() on the observer

Question

  • Why is the getEvent() method called in example #1 ? Or why is getEvent() not called in example #2 ?
  • What's the purpose of the getEvent() method ?
  • Where should one use getEvent() and where shouldn't one use it ?

3 Answers 3

7

It probably has historical reasons, reaching back beyond the 1.0 release.

The Varien_Event object is the logical place to contain parameters for a concrete event, but since Magento passes a Varien_Observer object to all observer methods, shortcut access the parameters made sense (and it has been there at least since 1.1).

I actually don't see any value in two different objects as they are used today.

But it obviously not was planned like that from the beginning. In the method Mage::addObserver(), not only the event and observer names and static arguments from the <args> XML node are set, but also a callback:

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

This way, the observers are able to dispatch themselves, with $observer->dispatch($event). In that case, the observers would not have the event data on themselves and you would need you use getEvent() to access it. But the method is not used anywhere, so in practice it does not matter.

If you want to practice some software archaeology and dig more, you'll find more dead code that hints on original ideas that never made it into the final product, like the Varien_Event_Observer_Collection.

1
  • Thank you. Was going to mention about "historical" aspects. Seems like you did that for us :) Commented Jun 21, 2016 at 8:12
8

One thing is clear.

Calling $observer->getEvent()->getSomething() and $observer->getSomething() return the same thing.

Take a look at the Mage_Core_Model_App::dispatchEvent method.

At one point you have $event = new Varien_Event($args); where $args are the arguments passed to the dispatchEvent method.
And Varien_Event extends Varien_Object so you can magically access the elements in $args from the Varien_Event instance.

but there is also this line $observer->addData($args); where $args are the same things as above.

Varien_Event_Observer also extends Varien_Object so this allows you to magically access elements in $args via the Observer object.

Conclusion:

The $_data member in the Observer class and Event class contain kind of the same things. The observer has in addition a few other fields. like event, event_name.

Let's say the $args look like this:

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

When dispatching the event, the $_data in the Event object would look like this:

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

and in the Observer class would looks like this:

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

But I cannot answer to why this lack of consistency exists.
I can only speculate that the code was written by 2 different developers.
If it's worth something, I always use $observer->getEvent()->getSomething().

[EDIT]

Why is the getEvent() method called in example #1 ? Or why is getEvent() not called in example #2 ?

Lack of consistency

What's the purpose of the getEvent() method ?

The Varien_Event object should be a wrapper object over the arguments passed to the observer

Where should one use getEvent() and where shouldn't one use it ? Use them as you like. You will get the same result all the time.

3
  • Got the explanation regarding lack of consistency, see my answer Commented Jun 21, 2016 at 8:07
  • I always perfer $observer->getEvent() to grab any data in observer. I know we can grab data from $observer directly. But I don't do that because I always feel, injection of object Varien_Event is very specific to hold event data. Hence I always depend on event object. I feel that's the correct approach. Commented Jun 21, 2016 at 8:10
  • @RajeevKTomy see my answer, there's actually no point of using getEvent() except if you need the event name OR want to be Magento 1.0 compatible Commented Jun 21, 2016 at 8:15
3

Explanation regarding lack of consistency.

According to Vinai and what Vitaly Korotun told him at some point:

getEvent() is legacy. Back in Magento 1.0 days the event data could not be pulled from the observer directly.

So if you don't need to get event_name and don't care too much about your code being Magento 1.0 compatible, you can leave out getEvent().

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.