In a recent post to his site Loïc Faugeron has posted the second in his series of in-depth looks at a specific component of the Symfony framework. In this new article he provides the "ultimate developer guide" to the EventDispatcher component.

In this guide we explore the standalone libraries (also known as "Components") provided by Symfony to help us build applications. We've already seen [the] [HTTP Kernel and HTTP Foundation](https://gnugat.github.io/2016/02/03/ultimate-symfony-http-kernel.html). We're now about to check Event Dispatcher, then in the next articles we'll have a look at: routing and YAML, dependency injection and console [functionality].

He starts off with a basic introduction to the EventDispatcher component, describing the EventDispatcherInterface and how to implement the class with simple listeners and dispatch handling. He also shows how to extend this and create Event class implementations. Following this he circled back around to the HttpKernel component and describes how it makes heavy use of events in things like routing, controller requests, exceptions and views. For each he gives a bit of example code defining listeners that perform simple actions when executed.

In a new post to his site Frank de Jonge makes a distinction between packages versus components, pointing out that components are always packages but packages are not always components, and what it really boils down to is a problem of dependency.

The PHP landscape has fully transitioned into its Package Age™ [...] However, due to PHP's nature, there are some problems. While packages are great for re-use outside of frameworks, dependencies are still an issue. Namespaces resolve conflicts between classnames, but they do not offer a solution to package versioning. Especially in a framework-context, this can become very problematic. A real-world-example for this is Guzzle.

In his Guzzle example he describes the main problem - when packages restructure or make changes incompatible with prior versions and dependencies conflict and both must be installed. He also points out that, while this is bad for just packages, it can be made even worse working with components (his name for framework-based packages). Problems he mentions are the previously mentioned dependency conflicts but also some unexpected quirks with how Composer chooses to install packages. He gives an example of this second one with the installation of the Symfony EventDispatcher component and how, upon closer inspection, Composer seems to be installing two versions of the library at once.

The ServerGrove blog continues their spotlight on the various components that make up the Symfony2 framework in their latest post about the EventDispatcher.

For many years, in the PHP world we were used to code following a linear flow, where instructions were executed one after another, jumping to functions or methods. Events change the way we design our software and allow us to decouple different parts creating small and reusable classes with a well-defined goal.

The post includes a brief introduction to the Mediator design pattern and how the EventDispatcher implements it. Sample code is included showing how to make a dispatcher, add events and dispatch an event to a waiting listener. There's also a comparison between "event listeners" and "event subscribers", pointing out that the latter has more flexibility when it comes to event priority.

Gonzalo Ayuso has posted a new tutorial today showing you how to combine PHP, Swiftmailer and Twig to send automated emails from your application.

My work as host is basically pick the place and encourage people to join to the Coding Dojo. One way of doing this (besides twitter buzz) is take my address book and send one bulk email to all of them inviting to join us. I don't like this kind of mails. They look like spam, so I prefer to send a personalized email. This email has a common part (the place location, the hour, the event description, ...) and the personalized part. I can do it manually, the list isn't so huge, but definitely that's not cool. Because of that I have done a little script to perform this operation.

His example extracts the information from a simple spreadsheet exported as a CSV file. He creates a simple Mailer class that uses Swiftmailer to do the actual sending. You pass in the Twig rendering object (Twig_Environment) that's used to render the email output. He includes a "Spammer" class that uses the Symfony EventDispatcher to send the email if everything works or an error email if something fails. He then drops it all into a Symfony Console command structure, defines several configuration settings in a "config.yml" and makes the script to execute the commands.