Fabien Potencier

About Symfony: Stability over Features

2013-04-15T11:35:00+02:00

I know that this post won't please everyone, but I'm convinced that this is the right thing to do now and I think that most of the Symfony community will love it. Also, I've tried to be subtle in choosing my words, so read carefully and don't over-read what I've written.

Long story short: in the coming months, the Symfony core contributors should focus their efforts toward stabilizing the existing features instead of working on new ones. At this point, backward compatibility and stability are more important than everything else.

Symfony is one of the few PHP projects that has been promoting radical changes to the way developers work with PHP by leveraging many concepts, best practices, and design patterns from other languages and technologies. But Symfony is also one of the few to embrace true collaboration and sharing. That was not necessarily incompatible in the "early days" of Symfony2, but to continue doing both the right way, the community needs to slightly change its priorities.

To start easy, let's see what stabilization means for me:

Refactor less: We need to stop doing refactoring code for the sake of it. Sometimes, our code is not the best architected one, sometimes we could simplify some code, or make it easier to read, but if it does not make things easier for our users, we should avoid doing refactoring.
Fix more bugs and edge cases: Symfony has twenty-plus components, small and large, and we are commited to maintain them in the long term. And working on fixing bugs that people encounter or fixing edge cases is a must. Most developers prefer to work on new features rather than fixing bugs, but personnally, I do like fixing bugs because most of time fixing a bug is a challenge... and we like challenges, right?
Write more tests: Symfony2 has many unit tests but we need more. We need to write tests that cover bugs and edge cases that we fix, but some parts of the framework are not well tested enough.
Write more documentation: Thanks to a great doc team, Symfony2 documentation is really good and it is updated and improved every single day. We should continue this work and the more people helping, the better. The good news is that everyone is able to contribute here.
Stop breaking backward compatibility: This is the most important topic and I know that many core contributors are nervous about this one. When we break backward compatibility, we are breaking the Symfony2 ecosystem at large. So, except when fixing a security issue, we must not break backward compatibility anymore after Symfony 2.3 and until Symfony 3.0.

Let's take some examples to make things clear.

What about fixing a wrong or stupid behavior on an existing feature? As we cannot break backward compatibility, and because people might rely on the current behavior, we should add a way to do the feature the right way instead and thoroughly document both behaviors by emphasizing the right way and by deprecating the wrong way until Symfony 3.0.

What about renaming a miss-named thing? We cannot rename the method/class/function/namespace/whatever, but we can add an alias and deprecate the wrong one, which will be removed in Symfony 3.0.

What about a new feature then? Of course, we will still add new features. If it does not impact the stability of the framework, that's fine: adding the new table helper for the console is a great example for instance, or supporting PIDs in the process component. But I believe that we already have a solid set of features that can be used to solve many complex web problems. And most of the time, for features that we don't have, there is already a good PHP librairies that we should leverage instead.

What about adding a new component? Again, that's still possible either by extracting code from other components (like we did for the new Debug component in 2.3 -- and without breaking backward compatibility), or by adding new ones, but that should not be our priority for the coming months.

Stability is also a great enabler:

Enhance performance: I'm not talking about micro-optimizations here, but performance on real projects. It was not really practical until now because Symfony2 was a moving target, but stabilization will enable us to make performance test beds and benchmarks to ensure that performance improves with new releases.
Convert more projects: I'm really happy that so many Open-Source projects rely on Symfony one way or another, but we need to convert more. By promoting sharing, we also promote reusability and compatibility between many different PHP projects, and that's a very good thing to do.
Convert more "corporate" users: When working in big companies, you need to plan your work ahead of time and for many years. So, you can only work with librairies that are maintained and stable in the long term.

I also want to point out that I've tested this approach with Twig. Twig version 1.12.3, released last week, is enterily backward compatible with Twig 1.0, released two years ago (to be fair, we made one mistake in 1.2 if I remember correctly). Of course, Twig is much smaller than Symfony, but if you take each Symfony component as an individual library, then the same approach can be applied. Last year, I started to work on Twig 2.0 because I thought that introducing some great features was not possible with the current architecture, but with some more work, I did introduce everything I wanted in Twig 1 without breaking backward compatibility. That's a big win. And that's probably one of the reasons why so many projects plan to use Twig nowadays (Drupal, eZPublish, Magento2, ...): Twig evolves fast but in a stable way. By the way, that's why namespaces won't be introduced in Twig anytime soon: we don't have a need for them.

At this point, I should probably answer one question: when will Symfony3 be released? As you might have guessed now, there is no plan or schedule for Symfony3; so it's not going to be released anytime soon. We do have an UPGRADE file for Symfony3, but only because we need to reference deprecated features that will be supported for all 2.x versions but that will be removed for Symfony3. And these deprecated features won't trigger any deprecation messages until we have a plan for Symfony3. So, you can upgrade to the new way, but not doing so won't affect you at all.

I hope that this strategy won't slow down the number of contributions. I believe that it will ease the adoption of Symfony2 and I believe that it won't stop us from innovating. And by making a stronger contract with our users, we are opening great opportunities for the Symfony ecosystem: bundles, libraries, projects, frameworks, CMSes, e-commerce solutions, ...

To conclude, think of Symfony as being a PHP middleware instead of a PHP framework and everything should click. This is just the beginning of the Symfony story, let's make it strong and awesome together.

Don't use PHP libraries with known security issues

2013-02-19T16:04:00+01:00

If you are a "connected" developer, you are probably aware of the major vulnerabilities found in Ruby on Rails recently. To be fair, we've also found some serious issues in the Symfony code during the last few months.

As security management should be a top most priority for us and our customers, I've recently worked on improving the current situation in the Symfony world, with an enhanced security process. But security management is also a very important topic for me because Symfony is quickly growing in popularity for both end-user projects and Open-Source ones; and more exposure also means more interest from the "bad guys".

One of the goal of good security issues management is transparency. That's why the Symfony project has a simple way of reporting security issues (via the security [at] symfony.com email address), an easily accessible list of security advisories, and a well defined blog post template to announce security issues. Recently, we have also enforced the need to have a CVE identifier for all security issues to help the broader community to be aware of Symfony security issues.

The best advice one can give you is to upgrade your favorite libraries as soon as possible when new versions with security fixes are released. Easier say than done.

How do you know that a new release is out? How do you know that it contains security fixes? For Symfony, you can subscribe to the RSS feed of the Symfony blog, or you can have a look at our security advisories from time to time. But sometimes, that's not possible as the project does not even have a blog. Was the security fix announced on Twitter? Quite possible. But most of the time, smaller libraries just release a new version without any proper security announcement.

But I want to provide a simple and efficient way to check for vulnerabilities in a project and I want to serve more than just the Symfony community. That's why I'm really proud to announce a new SensioLabs initiative: a simple way to check if your project depends on third-party libraries with known security issues. The website explains how it works in details (https://security.sensiolabs.org/), but basically, this initiative gives you several ways to check for security issues in your project dependencies based on the information contained in you composer.lock file (you are using Composer to manage your dependencies, right?):

The website itself allows you to upload a composer.lock to check for vulnerabilities;
A web service can used with curl or to integrate that tool into your own continuous integration process (it returns its results as plain text or as a JSON array);
A command line tool gives you the same feature as the web service and the website but nicely packaged as a simple Symfony command.

Of course, the most important part of this initiative is the database where known security vulnerabilities are referenced. The database is hosted on Github: https://github.com/sensiolabs/security-advisories. We have already referenced known vulnerabilities for Symfony, Zend Framework, and some well-known Symfony bundles, but the idea is for the community to help us add more libraries and more importantly to update the database whenever a security issue is fixed in a library. Even if you don't have a way to easily announce your security fix to the world, at least, reference it in the database; contributing to the database is really easy: fork the repository, contribute your changes, and send a pull request (you can even do everything from the Github web interface if you want).

Check your projects, upgrade your dependencies when needed, and contribute to the database!

Debugging Silex applications just got fun

2013-02-07T16:45:00+01:00

What is the difference between a full-stack framework and a micro framework? To me, this is not about the amount of code, but more about how you build an application and how you structure it. Symfony and Silex share a lot of code (Silex specific code being quite minimal), but developing an application with one or the other is a totally different experience. And choosing between the two really depends on your needs, the application you want to create, the skills of your team, etc...

One of the big advantages of both Symfony and Silex is that they are based on the Symfony HttpKernel component. Why is it an advantage? One of the reasons is the standardization of the HTTP dialog between the client and the application server and the standardization of the HTTP messages via the HttpFoundation component; that makes all applications using it easily interoperable (like Drupal, eZPublish, Laravel, and many others).

But handling HTTP requests with the Symfony HttpKernel also gives you a lot of free and optional features like a built-in reverse proxy written in PHP, easy handling of ESI and Hincludes (via the Fragment sub-framework), or the gorgeous Symfony web profiler:

I've just published a Silex provider that integrates the Symfony web profiler into Silex.

To get started faster, create a new application via my Silex Skeleton, where the profiler is already integrated and available when in the development environment:

composer create-project fabpot/silex-skeleton somewhere/ 1.0.x-dev

Igor recently wrote about HttpKernel and HttpFoundation on his blog... interesting read.

Why Symfony?

2012-09-07T11:22:00+02:00

Yesterday, Zend Framework 2.0 and Symfony 2.1 were released... almost at the same time. First, I want to congratulate the Zend Framework team for this huge milestone; I know that working on a new major version is no small task.

And of course, people started to ask questions about these new versions and one of the most popular was: "Why would I choose framework X over framework Y?". As you can imagine, the answer is not that easy as each framework has its own specificities.

I like to think that most popular frameworks are modular enough, fast enough, well-documented enough; they are using well-known design patterns. So, besides the buzzwords, what is unique to Symfony? Why would you want to use Symfony instead of X (replace X with ZF, CakePHP, Lithium, Laravel, Slim, Yii, you name it)? That's the question I'm going to answer in this post.

So, without further ado, here are my main selling points for Symfony:

Symfony is not a framework but a project. Depending on your needs, you can choose to use some of the Symfony Components, the Silex micro-framework, or the full-stack framework.
Symfony is used by many large companies (like the BBC or CBS), by many large websites (like TED, wetter.com, Lockers or even YouPorn just to name a few) and some Open-Source projects are also powered by Symfony (CMSes like Drupal or eZpublish, libraries like PHPUnit or Doctrine, products like phpBB or shopware, and even frameworks like PPI or Laravel). This brings a lot of interoperability between all these solutions.
Symfony enjoys a huge community of users and contributors; during the last year alone, 550+ people contributed to the Symfony core and the community created over 1,600 bundles for the full-stack framework. Symfony also has several annual dedicated conferences around the world and a large number of user groups.
Symfony has been created in 2005 and here to stay. Besides SensioLabs, many other companies rely on Symfony for their clients and they contribute, invest money, and sponsor the future of the project.
Symfony embraces the "don't reinvent the wheel" philosophy, and provides tight integration with many other Open-Source projects (like Monolog, Assetic, Doctrine, Propel, ...).
Symfony tries to bring innovation to PHP: it was one of the first major frameworks to embrace PHP 5.3, to introduce the usage of a Dependency Injection container, and to use a templating engine for its templates by default, Twig, which is now also adopted by major CMSes like Drupal and eZpublish. Symfony also has some unique features like its gorgeous debug toolbar and its great built-in profiler.

If you think I've missed some important selling points, feel free to list them in the comments and in a few days, I will aggregate everything in a new page that will be hosted on symfony.com to help users make an informed decision when choosing a framework.

And if other frameworks would like to do the same, I would happily add links to their pages on the Symfony one, and if in turn, they do the same, that would create a ring of links that will ease the choice of a PHP framework for developers.

PHP is much better than you think

2012-07-04T09:55:00+02:00

Rants about PHP are everywhere, and they even come from smart guys. When Jeff Atwood wrote yet another rant about PHP, it made me think about the good parts of PHP.

The biggest problem of these rants is that they come from people stuck in the old days of PHP. They either don't care or they don't want to admit that PHP actually evolves at a very fast pace, both at the language level but also at the community level. In fact, it evolves much faster than any other language or web platform. It has not always been the case, but the last 5 years have been an amazing journey for PHP.

Before talking about the amazing things the PHP community has achieved recently, let's have a look at some interesting numbers: PHP is used by 77.9% of all the websites whose server-side programming language is known. WordPress is used by 16.6% of all the websites in the world. If you have a look at the top three CMSes, for the websites that use a monitored content management system: Wordpress is first with 54.3%, Joomla is second with 9.2%, and Drupal is third with 6.8%. Three products written in PHP.

PHP must have done something right, no?

Now, let me tell you a secret, the PHP "tour de force": Despite the changes over the years, PHP is still the easiest language to learn for non-technical people: it allows anyone to create dynamic websites faster than with any other technologies, it allows anyone to host websites cheaply and without any hassles. PHP is probably not the best designed language in the world, but it lets you get things done, and you can't argue with that.

PHP, the Language

PHP 5.0 (released in 2004) brought us a very solid object model... wait a minute, I'm talking about something released almost 8 years ago. Fast forward now. The latest PHP release, PHP 5.4, comes with all the bells and whistles you might dream of in a modern web language: yes, PHP supports namespaces; yes, PHP supports closures; yes, PHP supports traits.

It took some time, but PHP 5.4 also comes with some nice syntactic sugar that makes the whole experience better than ever: yes, PHP supports [] to define arrays; yes, PHP supports calling a method on a newly created object ((new Foo())->bar()); yes, PHP supports getting an array item from any expression ($foo->bar()[1]).

PHP has even learned from its mistakes: register_globals and magic_quotes are definitely gone.

Last, but not the least, PHP even comes with a built-in web server that eases local testing... and it starts in a matter of micro-seconds.

Next challenges: How do we "upgrade" all the old tutorials talking about PHP on the web? What is the best way to support the WebSocket technology in a PHP application?

PHP, the Ecosystem

Having a good language is great, but having a great ecosystem is even better. And the PHP ecosystem has evolved a lot in the last few years.

Git

I won't talk too much about this one. Git is everywhere and PHP embraced Git pretty fast. Almost all major PHP libraries, frameworks, and products are now using Git, including PHP itself.

Composer

Two years ago, I wanted to get rid of my ugly-PEAR-hack I did in symfony 1 to support plugins. I wanted to replace it with something that was able to manage project dependencies, not a global installer like PEAR. Managing dependencies is not an easy task, so I tried to find the best algorithm to manage software dependencies; I had a look at everything: from Perl to Ruby, from Debian to Redhat. Nothing was satisfactory: only homegrown solutions that happen to work... empirically. Then, I stumbled upon ZYpp. That was it. ZYpp uses a SAT solver to manage dependencies. Fast forward. Thanks to the hard work of Nils Adermann and Jordi Boggiano, PHP now has one of the best dependency manager, Composer.

Yes, PHP has a better dependency manager than any other languages.

And thanks to Git, Composer, and the PHP built-in web server, it has never been easier to download/install/test a PHP project.

Want to test Symfony (using PHP 5.4)?

$ composer.phar create-project symfony/framework-standard-edition
$ cd framework-standard-edition
$ ./app/console server:run

Want to test Silex?

$ composer.phar create-project fabpot/silex-skeleton
$ cd silex-skeleton
$ php -S localhost:8888 -t web/

Don't know Composer yet? You should learn about it. Browse Packagist, the main Composer repository: it already has 1900+ packages available and they have been installed more than a million times in less than 3 months.

Next challenge: include the Composer installer in the next PHP version?

Collaboration

Community collaboration is the most important point of this post; the one I'm the most proud of. We start to see better collaboration between PHP projects, even from the very big ones, the ones you would think are large enough to not care about the others.

phpBB, Drupal, eZ Publish, Symfony, and many others (phpDocumentor, PHPUnit, Behat, Zikula, Propel, Doctrine, Midgard, ...) are sharing code. Yes, they are "competitors" but they all understood that cross-pollination was a good thing. And Composer is a good enabler.

Next challenge: Convince even more projects to join the trend.

Conclusion

Let me say it again: PHP is probably not the best language out there, and I'm the first one to scream about its quirks, but PHP is the best web platform... ever.

Sami: Yet another PHP API documentation generator

2012-05-15T13:58:00+02:00

Today is my "let open source some of my private Github repositories" day, and more specifically, I'm releasing a bunch of code related to documentation.

Earlier today, I've released the Sphinx extensions I'm using to generate the Symfony documentation.

And now, I'm releasing my API documentation generator. Yes, I know that PHP already has a bunch of such generators, but I started to work on this project several years ago, when the only viable option was the old phpdocumentor.

Nowadays, phpDocumentor version 2 is probably the best option out there as it has a good architecture, it works fine, it is extensible, and quite a few big PHP projects is already using it. And that's fine. I don't want to compete with it, I don't want to replace it, I'm just open sourcing some code used by Symfony, Twig, and Silex because I'm not comfortable with closed-source software. And to be totally honest and transparent, I have not released the code before because it was not "good enough".

With this disclaimer out of the way, let's see what makes Sami "different" (compared to phpdocumentor)?

It uses a PHP file for configuration to give a very flexible way of tweaking the API generation;
It uses Twig for templating;
It uses a dependency injection container (Pimple) to let you override any internal class;
It only works with PHP 5.3 (but it can generate documentation for PHP 5.2 projects);
It uses the excellent PHP Parser project for PHP code parsing;
It is able to manage versions of your code to generate documentation for all of them in a single tree (without the overhead of re-parsing everything for each version of course).

Curious about what Sami generates? Have a look at the Symfony API.

Installation

First, get Sami from Github (or integrate it as a dependency in your project Composer file -- you are using Composer, right?):

https://github.com/fabpot/Sami

You can also download an archive from Github.

As Sami uses Composer to manage its dependencies, installing it is a matter of running composer:

$ composer.phar install

Check that everything worked as expected by executing the sami.php file without any arguments:

$ php sami.php

Configuration

Before generating documentation, you must create a configuration file. Here is the simplest possible one:

<?php
 
return new Sami\Sami('/path/to/symfony/src');

The configuration file must return an instance of Sami\Sami and the first argument of the constructor is the path to the code you want to generate documentation for.

Actually, instead of a directory, you can use any valid PHP iterator (and for that matter any instance of the Symfony Finder class):

<?php
 
use Sami\Sami;
use Symfony\Component\Finder\Finder;
 
$iterator = Finder::create()
    ->files()
    ->name('*.php')
    ->exclude('Resources')
    ->exclude('Tests')
    ->in('/path/to/symfony/src')
;
 
return new Sami($iterator);

The Sami constructor optionally takes an array of options as a second argument:

return new Sami($iterator, array(
    'theme'                => 'symfony',
    'title'                => 'Symfony2 API',
    'build_dir'            => __DIR__.'/build',
    'cache_dir'            => __DIR__.'/cache',
    'default_opened_level' => 2,
));

And here is how you can configure different versions:

<?php
 
use Sami\Sami;
use Sami\Version\GitVersionCollection;
use Symfony\Component\Finder\Finder;
 
$iterator = Finder::create()
    ->files()
    ->name('*.php')
    ->exclude('Resources')
    ->exclude('Tests')
    ->in($dir = '/path/to/symfony/src')
;
 
// generate documentation for all v2.0.* tags, the 2.0 branch, and the master one
$versions = GitVersionCollection::create($dir)
    ->addFromTags('v2.0.*')
    ->add('2.0', '2.0 branch')
    ->add('master', 'master branch')
;
 
return new Sami($iterator, array(
    'theme'                => 'symfony',
    'versions'             => $versions,
    'title'                => 'Symfony2 API',
    'build_dir'            => __DIR__.'/../build/sf2/%version%',
    'cache_dir'            => __DIR__.'/../cache/sf2/%version%',
    'default_opened_level' => 2,
));

To generate documentation for a PHP 5.2 project, simply set the simulate_namespaces option to true.

Rendering

Now that we have a configuration file, let's generate the API documentation:

$ php sami.php update /path/to/config.php

The generated documentation can be found under the configured build/ directory (note that the client side search engine does not work on Chrome due to JavaScript execution restriction -- it works fine in Firefox).

By default, Sami is configured to run in "incremental" mode. It means that when running the update command, Sami only re-generates the files that need to be updated based on what has changed in your code since the last execution.

Sami also detects problems in your phpdoc and can tell you what you need to fix if you add the -v option:

$ php sami.php update /path/to/config.php -v

Creating a Theme

If the default themes do not suit your needs, you can very easily create a new one, or just override an existing one.

A theme is just a directory with a manifest.yml file that describes the theme (this is a YAML file):

name:   symfony
parent: enhanced

The above configuration creates a new symfony theme based on the enhanced built-in theme. To override a template, just create a file with the same name as the original one. For instance, here is how you can extend the default class template to prefix the class name with "Class " in the class page title:

{# pages/class.twig #}
 
{% extends 'default/pages/class.twig' %}
 
{% block title %}Class {{ parent() }}{% endblock %}

If you are familiar with Twig, you will be able to very easily tweak every aspect of the templates as everything has been well isolated in named Twig blocks.

A theme can also add more templates and static files. Here is the manifest for the default theme:

name: default
 
static:
    'stylesheet.css':        'stylesheet.css'
 
global:
    'index.twig':            'index.html'
    'namespaces.twig':       'namespaces-frame.html'
    'classes.twig':          'classes-frame.html'
    'pages/opensearch.twig': 'opensearch.xml'
    'pages/index.twig':      'doc-index.html'
    'pages/namespaces.twig': 'namespaces.html'
    'pages/interfaces.twig': 'interfaces.html'
    'pages/classes.twig':    'classes.html'
 
namespace:
    'namespace.twig':        '%s/namespace-frame.html'
    'pages/namespace.twig':  '%s.html'
 
class:
    'pages/class.twig':      '%s.html'

Files are contained into sections, depending on how Sami needs to treat them:

static: Files are copied as is (for assets like images, stylesheets, or JavaScript files);
global: Templates that do not depend on the current class context;
namespace: Templates that should be generated for every namespace;
class: Templates that should be generated for every class.

That's all there is to it for now. More documentation and a website is coming soon.

Create your own framework... on top of the Symfony2 Components (part 12)

2012-01-25T07:39:00+01:00

This article is part of a series of articles that explains how to create a framework with the Symfony2 Components: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12.

In the last installment of this series, we have emptied the Simplex\\Framework class by extending the HttpKernel class from Symfony. Seeing this empty class, you might be tempted to move some code from the front controller to it:

<?php
 
// example.com/src/Simplex/Framework.php
 
namespace Simplex;
 
use Symfony\Component\Routing;
use Symfony\Component\HttpKernel;
use Symfony\Component\EventDispatcher\EventDispatcher;
 
class Framework extends HttpKernel\HttpKernel
{
    public function __construct($routes)
    {
        $context = new Routing\RequestContext();
        $matcher = new Routing\Matcher\UrlMatcher($routes, $context);
        $resolver = new HttpKernel\Controller\ControllerResolver();
 
        $dispatcher = new EventDispatcher();
        $dispatcher->addSubscriber(new HttpKernel\EventListener\RouterListener($matcher));
        $dispatcher->addSubscriber(new HttpKernel\EventListener\ResponseListener('UTF-8'));
 
        parent::__construct($dispatcher, $resolver);
    }
}

The front controller code would become more concise:

<?php
 
// example.com/web/front.php
 
require_once __DIR__.'/../vendor/.composer/autoload.php';
 
use Symfony\Component\HttpFoundation\Request;
 
$request = Request::createFromGlobals();
$routes = include __DIR__.'/../src/app.php';
 
$framework = new Simplex\Framework($routes);
 
$framework->handle($request)->send();

Having a more concise front controller means that you can have more than one for a single application. Why would it be useful? To allow having different configuration for the development environment and the production one for instance. In the development environment, you might want to have error reporting turned on and errors displayed in the browser to ease debugging:

ini_set('display_errors', 1);
error_reporting(-1);

... but you certainly won't want that same configuration on the production environment. Having two different front controllers gives you the opportunity to have a slightly different configuration for each of them.

So, moving code from the front controller to the framework class makes our framework more configurable, but at the same time, it introduces a lot of issues:

We are not able to register custom listeners anymore as the dispatcher is not available outside the Framework class (an easy workaround could be the adding of a Framework::getEventDispatcher() method);
We have lost the flexibility we had before; you cannot change the implementation of the UrlMatcher or of the ControllerResolver anymore;
Related to the previous point, we cannot test our framework easily anymore as it's impossible to mock internal objects;
We cannot change the charset passed to ResponseListener anymore (a workaround could be to pass it as a constructor argument).

The previous code did not exhibit the same issues because we used dependency injection; all dependencies of our objects were injected into their constructors (for instance, the event dispatcher were injected into the framework so that we had total control of its creation and configuration).

Does it means that we have to make a choice between flexibility, customization, ease of testing and not having to copy and paste the same code into each application front controller? As you might expect, there is a solution. We can solve all these issues and some more by using the Symfony2 dependency injection container:

{
    "require": {
        "symfony/class-loader": "2.1.*",
        "symfony/http-foundation": "2.1.*",
        "symfony/routing": "2.1.*",
        "symfony/http-kernel": "2.1.*",
        "symfony/event-dispatcher": "2.1.*",
        "symfony/dependency-injection": "2.1.*"
    },
    "autoload": {
        "psr-0": { "Simplex": "src/", "Calendar": "src/" }
    }
}

Create a new file to host the dependency injection container configuration:

<?php
 
// example.com/src/container.php
 
use Symfony\Component\DependencyInjection;
use Symfony\Component\DependencyInjection\Reference;
 
$sc = new DependencyInjection\ContainerBuilder();
$sc->register('context', 'Symfony\Component\Routing\RequestContext');
$sc->register('matcher', 'Symfony\Component\Routing\Matcher\UrlMatcher')
    ->setArguments(array($routes, new Reference('context')))
;
$sc->register('resolver', 'Symfony\Component\HttpKernel\Controller\ControllerResolver');
 
$sc->register('listener.router', 'Symfony\Component\HttpKernel\EventListener\RouterListener')
    ->setArguments(array(new Reference('matcher')))
;
$sc->register('listener.response', 'Symfony\Component\HttpKernel\EventListener\ResponseListener')
    ->setArguments(array('UTF-8'))
;
$sc->register('listener.exception', 'Symfony\Component\HttpKernel\EventListener\ExceptionListener')
    ->setArguments(array('Calendar\\Controller\\ErrorController::exceptionAction'))
;
$sc->register('dispatcher', 'Symfony\Component\EventDispatcher\EventDispatcher')
    ->addMethodCall('addSubscriber', array(new Reference('listener.router')))
    ->addMethodCall('addSubscriber', array(new Reference('listener.response')))
    ->addMethodCall('addSubscriber', array(new Reference('listener.exception')))
;
$sc->register('framework', 'Simplex\Framework')
    ->setArguments(array(new Reference('dispatcher'), new Reference('resolver')))
;
 
return $sc;

The goal of this file is to configure your objects and their dependencies. Nothing is instantiated during this configuration step. This is purely a static description of the objects you need to manipulate and how to create them. Objects will be created on-demand when you access them from the container or when the container needs them to create other objects.

For instance, to create the router listener, we tell Symfony that its class name is Symfony\Component\HttpKernel\EventListener\RouterListeners, and that its constructor takes a matcher object (new Reference('matcher')). As you can see, each object is referenced by a name, a string that uniquely identifies each object. The name allows us to get an object and to reference it in other object definitions.

By default, every time you get an object from the container, it returns the exact same instance. That's because a container manages your "global" objects.

The front controller is now only about wiring everything together:

<?php
 
// example.com/web/front.php
 
require_once __DIR__.'/../vendor/.composer/autoload.php';
 
use Symfony\Component\HttpFoundation\Request;
 
$routes = include __DIR__.'/../src/app.php';
$sc = include __DIR__.'/../src/container.php';
 
$request = Request::createFromGlobals();
 
$response = $sc->get('framework')->handle($request);
 
$response->send();

As all the objects are now created in the dependency injection container, the framework code should be the previous simple version:

<?php
 
// example.com/src/Simplex/Framework.php
 
namespace Simplex;
 
use Symfony\Component\HttpKernel\HttpKernel;
 
class Framework extends HttpKernel
{
}

If you want a light alternative for your container, consider Pimple, a simple dependency injection container in about 60 lines of PHP code.

Now, here is how you can register a custom listener in the front controller:

$sc->register('listener.string_response', 'Simplex\StringResponseListener');
$sc->getDefinition('dispatcher')
    ->addMethodCall('addSubscriber', array(new Reference('listener.string_response')))
;

Beside describing your objects, the dependency injection container can also be configured via parameters. Let's create one that defines if we are in debug mode or not:

$sc->setParameter('debug', true);
 
echo $sc->getParameter('debug');

These parameters can be used when defining object definitions. Let's make the charset configurable:

$sc->register('listener.response', 'Symfony\Component\HttpKernel\EventListener\ResponseListener')
    ->setArguments(array('%charset%'))
;

After this change, you must set the charset before using the response listener object:

$sc->setParameter('charset', 'UTF-8');

Instead of relying on the convention that the routes are defined by the $routes variables, let's use a parameter again:

$sc->register('matcher', 'Symfony\Component\Routing\Matcher\UrlMatcher')
    ->setArguments(array('%routes%', new Reference('context')))
;

And the related change in the front controller:

$sc->setParameter('routes', include __DIR__.'/../src/app.php');

We have obviously barely scratched the surface of what you can do with the container: from class names as parameters, to overriding existing object definitions, from scope support to dumping a container to a plain PHP class, and much more. The Symfony dependency injection container is really powerful and is able to manage any kind of PHP classes.

Don't yell at me if you don't want to have a dependency injection container in your framework. If you don't like it, don't use it. It's your framework, not mine.

This is (already) the last part of my series on creating a framework on top of the Symfony2 components. I'm aware that many topics have not been covered in great details, but hopefully it gives you enough information to get started on your own and to better understand how the Symfony2 framework works internally.

If you want to learn more, I highly recommend you to read the source code of the Silex micro-framework, and especially its Application class.

Have fun!

~~ FIN ~~

P.S.: If there is enough interest (leave a comment on this post), I might write some more articles on specific topics (using a configuration file for routing, using HttpKernel debugging tools, using the build-in client to simulate a browser are some of the topics that come to my mind for instance).

Create your own framework... on top of the Symfony2 Components (part 11)

2012-01-23T13:51:00+01:00

This article is part of a series of articles that explains how to create a framework with the Symfony2 Components: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12.

If you were to use our framework right now, you would probably have to add support for custom error messages. Right now, we have 404 and 500 error support but the responses are hardcoded in the framework itself. Making them customizable is easy enough though: dispatch a new event and listen to it. Doing it right means that the listener has to call a regular controller. But what if the error controller throws an exception? You will end up in an infinite loop. There should be an easier way, right?

Enter the HttpKernel class. Instead of solving the same problem over and over again and instead of reinventing the wheel each time, the HttpKernel class is a generic, extensible, and flexible implementation of HttpKernelInterface.

This class is very similar to the framework class we have written so far: it dispatches events at some strategic points during the handling of the request, it uses a controller resolver to choose the controller to dispatch the request to, and as an added bonus, it takes care of edge cases and provides great feedback when a problem arises.

Here is the new framework code:

<?php
 
// example.com/src/Simplex/Framework.php
 
namespace Simplex;
 
use Symfony\Component\HttpKernel\HttpKernel;
 
class Framework extends HttpKernel
{
}

And the new front controller:

<?php
 
// example.com/web/front.php
 
require_once __DIR__.'/../vendor/.composer/autoload.php';
 
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing;
use Symfony\Component\HttpKernel;
use Symfony\Component\EventDispatcher\EventDispatcher;
 
$request = Request::createFromGlobals();
$routes = include __DIR__.'/../src/app.php';
 
$context = new Routing\RequestContext();
$matcher = new Routing\Matcher\UrlMatcher($routes, $context);
$resolver = new HttpKernel\Controller\ControllerResolver();
 
$dispatcher = new EventDispatcher();
$dispatcher->addSubscriber(new HttpKernel\EventListener\RouterListener($matcher));
 
$framework = new Simplex\Framework($dispatcher, $resolver);
 
$response = $framework->handle($request);
$response->send();

RouterListener is an implementation of the same logic we had in our framework: it matches the incoming request and populates the request attributes with route parameters.

Our code is now much more concise and surprisingly more robust and more powerful than ever. For instance, use the built-in ExceptionListener to make your error management configurable:

$errorHandler = function (HttpKernel\Exception\FlattenException $exception) {
    $msg = 'Something went wrong! ('.$exception->getMessage().')';
 
    return new Response($msg, $exception->getStatusCode());
});
$dispatcher->addSubscriber(new HttpKernel\EventListener\ExceptionListener($errorHandler));

ExceptionListener gives you a FlattenException instance instead of the thrown Exception instance to ease exception manipulation and display. It can take any valid controller as an exception handler, so you can create an ErrorController class instead of using a Closure:

$listener = new HttpKernel\EventListener\ExceptionListener('Calendar\\Controller\\ErrorController::exceptionAction');
$dispatcher->addSubscriber($listener);

The error controller reads as follows:

<?php
 
// example.com/src/Calendar/Controller/ErrorController.php
 
namespace Calendar\Controller;
 
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Exception\FlattenException;
 
class ErrorController
{
    public function exceptionAction(FlattenException $exception)
    {
        $msg = 'Something went wrong! ('.$exception->getMessage().')';
 
        return new Response($msg, $exception->getStatusCode());
    }
}

Voilà! Clean and customizable error management without efforts. And of course, if your controller throws an exception, HttpKernel will handle it nicely.

In part 2, we have talked about the Response::prepare() method, which ensures that a Response is compliant with the HTTP specification. It is probably a good idea to always call it just before sending the Response to the client; that's what the ResponseListener does:

$dispatcher->addSubscriber(new HttpKernel\EventListener\ResponseListener('UTF-8'));

This one was easy too! Let's take another one: do you want out of the box support for streamed responses? Just subscribe to StreamedResponseListener:

$dispatcher->addSubscriber(new HttpKernel\EventListener\StreamedResponseListener());

And in your controller, return a StreamedResponse instance instead of a Response instance.

Read the Internals chapter of the Symfony2 documentation to learn more about the events dispatched by HttpKernel and how they allow you to change the flow of a request.

Now, let's create a listener, one that allows a controller to return a string instead of a full Response object:

class LeapYearController
{
    public function indexAction(Request $request, $year)
    {
        $leapyear = new LeapYear();
        if ($leapyear->isLeapYear($year)) {
            return 'Yep, this is a leap year! ';
        }
 
        return 'Nope, this is not a leap year.';
    }
}

To implement this feature, we are going to listen to the kernel.view event, which is triggered just after the controller has been called. Its goal is to convert the controller return value to a proper Response instance, but only if needed:

<?php
 
// example.com/src/Simplex/StringResponseListener.php
 
namespace Simplex;
 
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent;
use Symfony\Component\HttpFoundation\Response;
 
class StringResponseListener implements EventSubscriberInterface
{
    public function onView(GetResponseForControllerResultEvent $event)
    {
        $response = $event->getControllerResult();
 
        if (is_string($response)) {
            $event->setResponse(new Response($response));
        }
    }
 
    public static function getSubscribedEvents()
    {
        return array('kernel.view' => 'onView');
    }
}

The code is simple because the kernel.view event is only triggered when the controller return value is not a Response and because setting the response on the event stops the event propagation (our listener cannot interfere with other view listeners).

Don't forget to register it in the front controller:

$dispatcher->addSubscriber(new Simplex\StringResponseListener());

If you forget to register the subscriber, HttpKernel will throw an exception with a nice message: The controller must return a response (Nope, this is not a leap year. given)..

At this point, our whole framework code is as compact as possible and it is mainly composed of an assembly of existing libraries. Extending is a matter of registering event listeners/subscribers.

Hopefully, you now have a better understanding of why the simple looking HttpKernelInterface is so powerful. Its default implementation, HttpKernel, gives you access to a lot of cool features, ready to be used out of the box, with no efforts. And because HttpKernel is actually the code that powers the Symfony2 and Silex frameworks, you have the best of both worlds: a custom framework, tailored to your needs, but based on a rock-solid and well maintained low-level architecture that has been proven to work for many websites; a code that has been audited for security issues and that has proven to scale well.

Create your own framework... on top of the Symfony2 Components (part 10)

2012-01-21T08:43:00+01:00

This article is part of a series of articles that explains how to create a framework with the Symfony2 Components: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12.

In the conclusion of the second part of this series, I've talked about one great benefit of using the Symfony2 components: the interoperability between all frameworks and applications using them. Let's do a big step towards this goal by making our framework implement HttpKernelInterface:

namespace Symfony\Component\HttpKernel;
 
interface HttpKernelInterface
{
    /**
     * @return Response A Response instance
     */
    function handle(Request $request, $type = self::MASTER_REQUEST, $catch = true);
}

HttpKernelInterface is probably the most important piece of code in the HttpKernel component, no kidding. Frameworks and applications that implement this interface are fully interoperable. Moreover, a lot of great features will come with it for free.

Update your framework so that it implements this interface:

<?php
 
// example.com/src/Framework.php
 
// ...
 
use Symfony\Component\HttpKernel\HttpKernelInterface;
 
class Framework implements HttpKernelInterface
{
    // ...
 
    public function handle(Request $request, $type = HttpKernelInterface::MASTER_REQUEST, $catch = true)
    {
        // ...
    }
}

Even if this change looks trivial, it brings us a lot! Let's talk about one of the most impressive one: transparent HTTP caching support.

The HttpCache class implements a fully-featured reverse proxy, written in PHP; it implements HttpKernelInterface and wraps another HttpKernelInterface instance:

// example.com/web/front.php
 
use Symfony\Component\HttpKernel\HttpCache\HttpCache;
use Symfony\Component\HttpKernel\HttpCache\Store;
 
$framework = new Simplex\Framework($dispatcher, $matcher, $resolver);
$framework = new HttpCache($framework, new Store(__DIR__.'/../cache'));
 
$framework->handle($request)->send();

That's all it takes to add HTTP caching support to our framework. Isn't it amazing?

Configuring the cache needs to be done via HTTP cache headers. For instance, to cache a response for 10 seconds, use the Response::setTtl() method::

// example.com/src/Calendar/Controller/LeapYearController.php
 
public function indexAction(Request $request, $year)
{
    $leapyear = new LeapYear();
    if ($leapyear->isLeapYear($year)) {
        $response = new Response('Yep, this is a leap year!');
    } else {
        $response = new Response('Nope, this is not a leap year.');
    }
 
    $response->setTtl(10);
 
    return $response;
}

If, like me, you are running your framework from the command line by simulating requests (Request::create('/is_leap_year/2012')), you can easily debug Response instances by dumping their string representation (echo $response;) as it displays all headers as well as the response content.

To validate that it works correctly, add a random number to the response content and check that the number only changes every 10 seconds:

$response = new Response('Yep, this is a leap year! '.rand());

When deploying to your production environment, keep using the Symfony2 reverse proxy (great for shared hosting) or even better, switch to a more efficient reverse proxy like Varnish.

Using HTTP cache headers to manage your application cache is very powerful and allows you to tune finely your caching strategy as you can use both the expiration and the validation models of the HTTP specification. If you are not comfortable with these concepts, I highly recommend you to read the HTTP caching chapter of the Symfony2 documentation.

The Response class contains many other methods that let you configure the HTTP cache very easily. One of the most powerful is setCache() as it abstracts the most frequently used caching strategies into one simple array:

$date = date_create_from_format('Y-m-d H:i:s', '2005-10-15 10:00:00');
 
$response->setCache(array(
    'public'        => true,
    'etag'          => 'abcde',
    'last_modified' => $date,
    'max_age'       => 10,
    's_maxage'      => 10,
));
 
// it is equivalent to the following code
$response->setPublic();
$response->setEtag('abcde');
$response->setLastModified($date);
$response->setMaxAge(10);
$response->setSharedMaxAge(10);

When using the validation model, the isNotModified() method allows you to easily cut on the response time by short-circuiting the response generation as early as possible:

$response->setETag('whatever_you_compute_as_an_etag');
 
if ($response->isNotModified($request)) {
    return $response;
}
$response->setContent('The computed content of the response');
 
return $response;

Using HTTP caching is great, but what if you cannot cache the whole page? What if you can cache everything but some sidebar that is more dynamic that the rest of the content? Edge Side Includes (ESI) to the rescue! Instead of generating the whole content in one go, ESI allows you to mark a region of a page as being the content of a sub-request call:

This is the content of your page
 
Is 2012 a leap year? <esi:include src="/leapyear/2012" />
 
Some other content

For ESI tags to be supported by HttpCache, you need to pass it an instance of the ESI class. The ESI class automatically parses ESI tags and makes sub-requests to convert them to their proper content:

use Symfony\Component\HttpKernel\HttpCache\ESI;
 
$framework = new HttpCache($framework, new Store(__DIR__.'/../cache'), new ESI());

For ESI to work, you need to use a reverse proxy that supports it like the Symfony2 implementation. Varnish is the best alternative and it is Open-Source.

When using complex HTTP caching strategies and/or many ESI include tags, it can be hard to understand why and when a resource should be cached or not. To ease debugging, you can enable the debug mode:

$framework = new HttpCache($framework, new Store(__DIR__.'/../cache'), new ESI(), array('debug' => true));

The debug mode adds a X-Symfony-Cache header to each response that describes what the cache layer did:

X-Symfony-Cache:  GET /is_leap_year/2012: stale, invalid, store
 
X-Symfony-Cache:  GET /is_leap_year/2012: fresh

HttpCache has many features like support for the stale-while-revalidate and stale-if-error HTTP Cache-Control extensions as defined in RFC 5861.

With the addition of a single interface, our framework can now benefit from the many features built into the HttpKernel component; HTTP caching being just one of them but an important one as it can make your applications fly!

Create your own framework... on top of the Symfony2 Components (part 9)

2012-01-19T13:09:00+01:00

This article is part of a series of articles that explains how to create a framework with the Symfony2 Components: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12.

Our framework is still missing a major characteristic of any good framework: extensibility. Being extensible means that the developer should be able to easily hook into the framework life cycle to modify the way the request is handled.

What kind of hooks are we talking about? Authentication or caching for instance. To be flexible, hooks must be plug-and-play; the ones you "register" for an application are different from the next one depending on your specific needs. Many software have a similar concept like Drupal or Wordpress. In some languages, there is even a standard like WSGI in Python or Rack in Ruby.

As there is no standard for PHP, we are going to use a well-known design pattern, the Observer, to allow any kind of behaviors to be attached to our framework; the Symfony2 EventDispatcher Component implements a lightweight version of this pattern:

{
    "require": {
        "symfony/class-loader": "2.1.*",
        "symfony/http-foundation": "2.1.*",
        "symfony/routing": "2.1.*",
        "symfony/http-kernel": "2.1.*",
        "symfony/event-dispatcher": "2.1.*"
    },
    "autoload": {
        "psr-0": { "Simplex": "src/", "Calendar": "src/" }
    }
}

How does it work? The dispatcher, the central object of the event dispatcher system, notifies listeners of an event dispatched to it. Put another way: your code dispatches an event to the dispatcher, the dispatcher notifies all registered listeners for the event, and each listener do whatever it wants with the event.

As an example, let's create a listener that transparently adds the Google Analytics code to all responses.

To make it work, the framework must dispatch an event just before returning the Response instance:

<?php
 
// example.com/src/Simplex/Framework.php
 
namespace Simplex;
 
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Matcher\UrlMatcherInterface;
use Symfony\Component\Routing\Exception\ResourceNotFoundException;
use Symfony\Component\HttpKernel\Controller\ControllerResolverInterface;
use Symfony\Component\EventDispatcher\EventDispatcher;
 
class Framework
{
    protected $matcher;
    protected $resolver;
    protected $dispatcher;
 
    public function __construct(EventDispatcher $dispatcher, UrlMatcherInterface $matcher, ControllerResolverInterface $resolver)
    {
        $this->matcher = $matcher;
        $this->resolver = $resolver;
        $this->dispatcher = $dispatcher;
    }
 
    public function handle(Request $request)
    {
        try {
            $request->attributes->add($this->matcher->match($request->getPathInfo()));
 
            $controller = $this->resolver->getController($request);
            $arguments = $this->resolver->getArguments($request, $controller);
 
            $response = call_user_func_array($controller, $arguments);
        } catch (ResourceNotFoundException $e) {
            $response = new Response('Not Found', 404);
        } catch (\Exception $e) {
            $response = new Response('An error occurred', 500);
        }
 
        // dispatch a response event
        $this->dispatcher->dispatch('response', new ResponseEvent($response, $request));
 
        return $response;
    }
}

Each time the framework handles a Request, a ResponseEvent event is now dispatched:

<?php
 
// example.com/src/Simplex/ResponseEvent.php
 
namespace Simplex;
 
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\EventDispatcher\Event;
 
class ResponseEvent extends Event
{
    private $request;
    private $response;
 
    public function __construct(Response $response, Request $request)
    {
        $this->response = $response;
        $this->request = $request;
    }
 
    public function getResponse()
    {
        return $this->response;
    }
 
    public function getRequest()
    {
        return $this->request;
    }
}

The last step is the creation of the dispatcher in the front controller and the registration of a listener for the response event:

<?php
 
// example.com/web/front.php
 
require_once __DIR__.'/../vendor/.composer/autoload.php';
 
// ...
 
use Symfony\Component\EventDispatcher\EventDispatcher;
 
$dispatcher = new EventDispatcher();
$dispatcher->addListener('response', function (Simplex\ResponseEvent $event) {
    $response = $event->getResponse();
 
    if ($response->isRedirection()
        || ($response->headers->has('Content-Type') && false === strpos($response->headers->get('Content-Type'), 'html'))
        || 'html' !== $event->getRequest()->getRequestFormat()
    ) {
        return;
    }
 
    $response->setContent($response->getContent().'GA CODE');
});
 
$framework = new Simplex\Framework($dispatcher, $matcher, $resolver);
$response = $framework->handle($request);
 
$response->send();

The listener is just a proof of concept and you should add the Google Analytics code just before the body tag.

As you can see, addListener() associates a valid PHP callback to a named event (response); the event name must be the same as the one used in the dispatch() call.

In the listener, we add the Google Analytics code only if the response is not a redirection, if the requested format is HTML, and if the response content type is HTML (these conditions demonstrate the ease of manipulating the Request and Response data from your code).

So far so good, but let's add another listener on the same event. Let's say that I want to set the Content-Length of the Response if it is not already set:

$dispatcher->addListener('response', function (Simplex\ResponseEvent $event) {
    $response = $event->getResponse();
    $headers = $response->headers;
 
    if (!$headers->has('Content-Length') && !$headers->has('Transfer-Encoding')) {
        $headers->set('Content-Length', strlen($response->getContent()));
    }
});

Depending on whether you have added this piece of code before the previous listener registration or after it, you will have the wrong or the right value for the Content-Length header. Sometimes, the order of the listeners matter but by default, all listeners are registered with the same priority, 0. To tell the dispatcher to run a listener early, change the priority to a positive number; negative numbers can be used for low priority listeners. Here, we want the Content-Length listener to be executed last, so change the priority to -255:

$dispatcher->addListener('response', function (Simplex\ResponseEvent $event) {
    $response = $event->getResponse();
    $headers = $response->headers;
 
    if (!$headers->has('Content-Length') && !$headers->has('Transfer-Encoding')) {
        $headers->set('Content-Length', strlen($response->getContent()));
    }
}, -255);

When creating your framework, think about priorities (reserve some numbers for internal listeners for instance) and document them thoroughly.

Let's refactor the code a bit by moving the Google listener to its own class:

<?php
 
// example.com/src/Simplex/GoogleListener.php
 
namespace Simplex;
 
class GoogleListener
{
    public function onResponse(ResponseEvent $event)
    {
        $response = $event->getResponse();
 
        if ($response->isRedirection()
            || ($response->headers->has('Content-Type') && false === strpos($response->headers->get('Content-Type'), 'html'))
            || 'html' !== $event->getRequest()->getRequestFormat()
        ) {
            return;
        }
 
        $response->setContent($response->getContent().'GA CODE');
    }
}

And do the same with the other listener:

<?php
 
// example.com/src/Simplex/ContentLengthListener.php
 
namespace Simplex;
 
class ContentLengthListener
{
    public function onResponse(ResponseEvent $event)
    {
        $response = $event->getResponse();
        $headers = $response->headers;
 
        if (!$headers->has('Content-Length') && !$headers->has('Transfer-Encoding')) {
            $headers->set('Content-Length', strlen($response->getContent()));
        }
    }
}

Our front controller should now look like the following:

$dispatcher = new EventDispatcher();
$dispatcher->addListener('response', array(new Simplex\ContentLengthListener(), 'onResponse'), -255);
$dispatcher->addListener('response', array(new Simplex\GoogleListener(), 'onResponse'));

Even if the code is now nicely wrapped in classes, there is still a slight issue: the knowledge of the priorities is "hardcoded" in the front controller, instead of being in the listeners themselves. For each application, you have to remember to set the appropriate priorities. Moreover, the listener method names are also exposed here, which means that refactoring our listeners would mean changing all the applications that rely on those listeners. Of course, there is a solution: use subscribers instead of listeners:

$dispatcher = new EventDispatcher();
$dispatcher->addSubscriber(new Simplex\ContentLengthListener());
$dispatcher->addSubscriber(new Simplex\GoogleListener());

A subscriber knowns about all the events it is interested in and pass this information to the dispatcher via the getSubscribedEvents() method. Have a look at the new version of the GoogleListener:

<?php
 
// example.com/src/Simplex/GoogleListener.php
 
namespace Simplex;
 
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
 
class GoogleListener implements EventSubscriberInterface
{
    // ...
 
    public static function getSubscribedEvents()
    {
        return array('response' => 'onResponse');
    }
}

And here is the new version of ContentLengthListener:

<?php
 
// example.com/src/Simplex/ContentLengthListener.php
 
namespace Simplex;
 
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
 
class ContentLengthListener implements EventSubscriberInterface
{
    // ...
 
    public static function getSubscribedEvents()
    {
        return array('response' => array('onResponse', -255));
    }
}

A single subscriber can host as many listeners as you want on as many events as needed.

To make your framework truly flexible, don't hesitate to add more events; and to make it more awesome out of the box, add more listeners. Again, this series is not about creating a generic framework, but one that is tailored to your needs. Stop whenever you see fit, and further evolve the code from there.