The TutsPlus.com site has posted another tutorial where they go in-depth with one of the components of the Symfony framework. In this new tutorial they cover the Symfony Event Dispatcher component including its basic use via events and subscribers.

Today, we're going to learn how to use the Symfony event dispatcher component, which allows you to create events and listeners in your PHP applications. Thus, different components of your application can talk to each other with loosely coupled code.

[...] The event dispatcher component provides three elements that you could build your app architecture around: event, listener, and dispatcher. The whole system is orchestrated by the dispatcher class, which raises events at appropriate points in an application and calls listeners associated with those events.

The tutorial starts with the command you'll need to get the dispatcher installed and examples of:

• creating events
• dispatching the events to subscribers
• listening for the events

The tutorial then covers subscribers, reusable listeners that can be added to the list for handling when an event fires. Code examples are included for all topics.

In a recent post to his site Tomáš Votruba shares what he sees as a "bulletproof" event naming scheme for use with the Symfony event dispatcher component.

I wrote intro to SymfonyEventDispatcher and how to use it with simple event.

But when it comes to dispatching events, you can choose from 4 different ways. Which one to choose and why? Today I will show you pros and cons of them to make it easier for you.

He then breaks up the remainder of the post into the four suggestions, each with code examples and brief descriptions:

• 1. Start with Stringly
• 2. Group File with Events Names as Constants
• 3. ...Constant Names in Particular Event Classes
• 4. Class-based Event Naming

For each he also includes some "pros" and "cons" to help you select which one might work best for your usage. He ends by taking things "a step further" and sharing integrating a suggestion to remove an argument and simplify the code.

The SitePoint PHP blog has a new tutorial posted today showing the interaction between Drupal 8 hooks and the Symfony dispatcher in the last part of their series showing how to build a custom Drupal 8 module.

With the incorporation of many Symfony components into Drupal in its 8th version, we are seeing a shift away from many Drupalisms towards more modern PHP architectural decisions. For example, the both loved and hated hook system is getting slowly replaced. Plugins and annotations are taking away much of the need for info hooks and the Symfony Event Dispatcher component is replacing some of the invoked hooks. Although they remain strong in Drupal 8, it’s very possible that with Drupal 9 (or maybe 10) hooks will be completely removed.

He starts off with a brief introduction to what the event dispatcher is and how it currently interacts with the Drupal 8 system. He uses a simple form example with two text fields and how to hook in the dispatcher to fire a "demo_form.save" event when the user submits the form. He ties this into a DemoEvent and sets up a simple subscriber. He ends the article with a look at using hooks to achieve the same kind of goal.

In his latest post Mathias Noback takes a look at the Symfony2 event subsystems and the answer to a common problem he's had with it in the past: circular references.

Recently I realized that some of the problems I encountered in the past could have been easily solved by what I'm about to explain in this post. [...] The problem is: having a complicated graph of service definitions and their dependencies, which causes a ServiceCircularReferenceException, saying 'Circular reference detected for service "...", path: "... -> ... -> ...".' Somewhere in the path of services that form the circle you then find the event_dispatcher service.

He shows the wrong way to solve the problem first by injecting a service container into the listener and using services directly from there. In his "entirely different and much better way" he shows a solution that removes dependencies on the main event dispatcher. He shows how to use the event subsystems to avoid this link and gives a more concrete example for domain-related events (with both code and config).

On the Aura framework blog there's a new post with a sneak peek at Aura.Dispatcher to handle the mapping between names and objects to handle the given request. The Aura framework provides high-quality, well-tested, standards-compliant, decoupled libraries that can be used in any codebase. This means you can use as much or as little of the project as you like.

In the lessons learned post, I talked about how Aura was born of the idea that we could extract independent decoupled packages from Solar, and how in doing so, we discovered that some of those extracted packages themsleves could be further split into independent pieces. Previously, I wrote about Aura.Sql-v2, Aura.Sql_Query, and Aura.Sql_Schema as extractions from a single Aura.Sql package. Today, I’m going to talk about Aura.Dispatcher as a combined extraction from three separate packages.

He starts off with a look at dispatchers in general, noting that they're usually used with request routing but the concept isn't limited to just that. He points out that CLI dispatching, as it turns out, is a lot like web request handling. The component makes routing both sides equally simple and could also be used as something like a micro-framework router. The post finishes up with this concept, talking about the evolution from micro- to full-stack framework structures and how the component could help.

Gonzalo Ayuso as a new post today showing the results of some of his testing with the event dispatcher and Silex to send logs to a remote server.

Today I continue playing with event dispatcher and Silex. Now I want to send a detailed log of our Kernel events to a remote server. We can do it something similar with Monolog, but I want to implement one working example hacking a little bit the event dispatcher. Basically we’re going to create one Logger class (implementing PSR-3 of course).

He includes the sample code defining a "Logger" class that takes whatever message sent to it and pushes it into a given socket resource. He also creates a provider for the logger to implement it in the example and registers it with the event dispatcher. He hooks it into the request, get controller, terminate and exception events. On the other side he uses React to make a basic server to listen on port 4000 for the incoming log data.

Gonzalo Ayuso has a new post today showing you how to use the Symfony event dispatcher in a Silex-based application. His example involves a simple image processing example.

Symfony has one component called The Event Dispatcher. This component is one implementation of Mediator pattern and it’s widely used in modern frameworks, such as Symfony. Silex, as a part of Symfony, also uses this component and we can easily use it in our projects.

His example creates a Silex endpoint that creates an image with a given string. He notes that handling it all at once and then unlinking at the end of the request is one way to handle it. The other is to use the event dispatcher to add an event lister (as a closure) to happen "on terminate" to unlink the path it's been given.

On the Symfony-framework.com website, there's a look at what's new in the latest Symfony build, version 1.1, as presented by Fabien Potencier at this year's International PHP Conference 2007.

In this article, I will briefly explain all the significant changes of Symfony 1.1 so that you will have fewer doubts deciding between: rewrite part of your old code, simply update your application or use the new Symfony 1.1 only in new developments.

There's three things he mentions - the new task framework to help organize code development, the reorganization of the event dispatcher and its dependencies, and the new Form, Widget and Validator framework.

On the Symfony-framework.com website, there's a look at what's new in the latest Symfony build, version 1.1, as presented by Fabien Potencier at this year's International PHP Conference 2007.

In this article, I will briefly explain all the significant changes of Symfony 1.1 so that you will have fewer doubts deciding between: rewrite part of your old code, simply update your application or use the new Symfony 1.1 only in new developments.

There's three things he mentions - the new task framework to help organize code development, the reorganization of the event dispatcher and its dependencies, and the new Form, Widget and Validator framework.

In his latest blog entry on the ThinkingPHP Blog, Felix Geisendörfer continues on with the series started here and shows that there's more to learn from the CakePHP source code.

In the previous post I was showing how to use the Dispatcher::dispatch() function. Now what’s more interesting, is what it actually does and in what order.

He lists out the order of the process the Dispatcher follows:

• Build the $params array
• Find the base url
• Load/Include the requested Controller
• Possible Plugin Logic
• Executing the Admin Route
• Render a possible missingController error
• Action exists? Action private?
• Set Controller variables
• Load Components & Models
• Render possible missingAction/privateActione errors
• Invoke the controller

It seems like a long way to go to just get the request to the right Controller, but it all happens in the blink of an eye when the page request is made.

If you've enjoyed the look at the Dispatcher, let Felix know - especially if you'd like to see other parts covered.