The fastest way to EventListener in Symfony2

img-listen-lrg

Event Driven Design is really popular topic for about two years and I don’t suprised this trend. You can really fast decouple parts of code without any influence on any other – you can send emails, saving logs or data to database without additional mess in your core class.

The main idea

As you can see on the diagram we need to implement, use or register a couple of extra class to properly use events in the system.

dispatcher_uml

Our central entry point of course ConreteClassFoo where we have implemented our business logic and we want to inform every registered EventListener that they can do whatever should they do. We can do this by calling method Dispatch in Dispatcher. To pass all required information from our class to each EvenListener we need to implement an Event. I believe it’s working more as a data structure than proper class, because it mostly stores actual data from ConreteClassFoo.

Step by step – ConreteClassFoo

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
use Symfony\Component\EventDispatcher\EventDispatcherInterface;

class ConcreteClassFoo
{

    /**
    * @var \Symfony\Component\EventDispatcher\EventDispatcherInterface
    **/

    protected $dispatcher;

    public function __construct(EventDispatcherInterface $dispatcher)
    {
        $this->dispatcher = $dispatcher;
    }
   
    public function awesomeWork()
    {
        //do your awesome work here
        //we will initialize Event object here, but later
        $this->dispatcher->dispatch('pp.awesome_work.before', /**???**/);
        //do your awesome work here
        $this->dispatcher->dispatch('pp.awesome_work.after', /**???**/);
    }
}

As you can see I have injected Dispatcher object to our class. Let’s just imagine the `awesomeWork` method is responsible for registering new user in very, very complex system. The system requires to send different emails to a couple of supervisors after action, maintain system logs, register new user in a few external webservices. I think we wouldn’t like to inject all of these objects to our class, do we? Once, I have heard a great principle about the number of parameters in every method – one is the best, two is cool, three is too much and you should redesign your solution. Moreover, this would be much more comfortable when you will write tests for your class – you need to mock only and only one method in our case – the dispatch.

When you will do this exercise on your own application you would probably notice that we need to somehow inject our dispatcher to the class and the Symfony’s documentation doesn’t tell as how (or it’s quite hard to find this). We can use `event_dispatcher` service:

1
2
3
4
5
services:
    pp.awesome_work.concrete_class_foo:
        class: ConcreteClassFoo
        arguments:
            - @event_dispatcher

But as you probably noticed I have put /**???**/ comments as a parameter and promised that we will do something with that and replace with proper object. Well, let’s do it.

A Principle about the number of parameters in every method – one is the best, two is cool, three is too much and you should redesign your solution

Event

As I wrote at the beginning we can pass a piece of information from our class or method to EventListeners. Using raw arrays is, of course, bad idea. Following the Symfony’s documentation we need to define our own data structure which will extends the Event class.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<?php

use Symfony\Component\EventDispatcher\Event;

class AwesomeWorkEvent extends Event
{

    /**
     * @var OneDataClass
     */

    protected $data;

    public function __construct(OneDataClass $data)
    {
        $this->data = $data;
    }

    public function getData()
    {
        return $this->data;
    }
}

This is the simplest example I can imagine, even for this article. We pass some class called OneDataClass which was made in awesomeWork method to the constructor (because our Event object cannot exist without any data inside).

So, we need to update our ConcreteClassFoo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
use Symfony\Component\EventDispatcher\EventDispatcherInterface;

class ConcreteClassFoo
{

    /**
    * @var \Symfony\Component\EventDispatcher\EventDispatcherInterface
    **/

    protected $dispatcher;

    public function __construct(EventDispatcherInterface $dispatcher)
    {
        $this->dispatcher = $dispatcher;
    }
   
    public function awesomeWork()
    {
        //do your awesome work here
        $beforeEvent = new AwesomeWorkEvent($someDataObject);
        $this->dispatcher->dispatch('pp.awesome_work.before', $beforeEvent);
        //do your awesome work here
        $afterEvent = new AwesomeWorkEvent($someDataObject);
        $this->dispatcher->dispatch('pp.awesome_work.after', $afterEvent);
    }
}

Edit: Why do we initiate AwesomeWorkEvent twice? Because @Stof70 said to do this (:D) and I think it makes sense:

The dispatcher allows to stop the propagation to next listeners by calling “$event->stopPropagation()“. As you reuse the same event instance for each dispatching, stopping the propagation of the first event will also stop the propagation of the second one (meaning it will never be dispatched to listeners).

We have added the instance of AwesomeWorkEvent called $event to dispatcher and assigned it to two actions. All event listeners will be called with this arguments now.

Listeners

That’s the last point. We need to perform our logic in some place and call actions.

1
2
3
4
5
6
7
8
9
namespace PP\AwesomeBundle\EventListener;

class AwesomeWorkListener
{
    public function doYourJob(AwesomeWorkEvent $event)
    {
        /** Do the right job **/
    }
}

So, now we’ve got the place, but the framework doesn’t know about this. We need to inform him in the configuration about our listener. To do this we can use specified tag:

1
2
3
4
5
6
;PP/AwesomeBundle/Resources/config/service.yml
services:
    pp_awesome.awesome.listener:
        class: %pp_awesome.awesome.listener.class%
        tags:
            - { name: kernel.event_listener, event: pp.awesome_work.before, method: doYourJob }

 
 
Of course, you can add more listeners to one dispatched event. If you want to see how to use Events and Event Listeners in more advanced example you can read a http://piotrpasich.com/query-manipulation/ and visit the github https://github.com/piotrpasich/symfony-search-solution .

Piotr

5 Comments

  1. Hi,

    There is a small issue in your example, which could create unwanted bugs in your code when you start using advanced features of the EventDispatcher component: the dispatcher allows to stop the propagation to next listeners by calling “$event->stopPropagation()“. As you reuse the same event instance for each dispatching, stopping the propagation of the first event will also stop the propagation of the second one (meaning it will never be dispatched to listeners).
    To avoid such issue, you should create a new event instance for each dispatching.

    Reply
    • Piotr,

      this exactly why I made this article. I’ll try to write something similar and push to Symfony’s documentation. I must admit this part i docs can be really confusing for beginners.

Leave a Comment.