You have created one or more Symfony applications. You found out how to leverage the framework to rapidly develop some features. As the application (and your team) got bigger, you started looking for a way to prepare your application for a long and prosperous life. After reading about DDD, BDD, events, command buses, layered and hexagonal architecture, you are left wondering: how can I apply these cool ideas to my everyday Symfony projects?

Class dependencies are things that your classes need. You may be used to fetching them yourself, but what if someone else could bring them to you? This is what the Symfony DependencyInjection Component can do for you. It converts service definitions to executable PHP code. The result is that all the dependencies of your classes will be injected as constructor arguments automatically.

Since Drupal 8 heavily uses dependency injection, you need to learn as much as you can about this interesting subject. In the workshop “A healthy dose of dependency injection” Matthias tells you all about the design principles behind dependency injection (like Inversion of control and Dependency inversion). And of course, you will learn all the little details of working with service definitions.

A Series of Fortunate Events

What is an event really? How can you best describe an event in your code? What types of events are there, and how do you decide whether or not to implement something as an event?

In this talk we start with a straightforward command-only piece of code. We extract events from it and start moving the event handling code out, trying different design patterns on the way. First we try Observer. Then we introduce event data, event handlers and a Mediator between our code and the event handlers. Finally we pick a well-known event dispatcher implementation (the Symfony EventDispatcher) and see how it uses the Chain of Responsibility design pattern to control the entire flow of a web application request.

You have created one or more Symfony applications. You’ve learned how to use the framework to rapidly develop some features: you wrote some controllers, entities and templates. But as the application (and your team) got bigger, you started looking for a way to prepare your application for a long and prosper life. Still, after reading about DDD, BDD, events, command buses, layered and hexagonal architecture, you are still wondering:

How can I apply these cool ideas to my Symfony applications?

The Bundle system is “one of the greatest and most powerful features of Symfony2”. Bundles contain all the files related to a single feature of your application: controllers, entities, event listeners, form types, Twig templates, etc. But how much of that actually needs to be inside a bundle?

In this talk I take a bundle, containing all those different types of classes, configuration files and templates, and strip it down to the bare necessities. And I promise that after moving many files out of the bundle, at the end everything still works.

Developers are able to modify the behavior and possibilities of Twig (the PHP templating engine by Fabien Potencier) in many ways, ranging from very easy to very tough. It all starts with simply registering your extension, but from then on you can choose to create your own filters, functions and tests. I will quickly review your options, and show some best practices. After discussing these basic modifications, we’ll take a look at creating token parsers and thinking up custom node types, which will enable you to define your own tags (the things between {% verbatim %}{% %}{% endverbatim %}). I will demonstrate the inner workings of Twig: from the loader, to the lexer, to the parser, to your own token parser, to creating nodes, filtering nodes using a node visitor and finally to the compiler, which transforms all nodes to plain old PHP.

With the rise of dependency injection (DI) containers, which may or may not also be service locators, it is now very easy to keep track of all the dependencies of your classes and to switch between implementations. The temptation of using the new operator has since become much smaller. Still, all the options of the containers and locators, the syntax of the service definitions and lack of knowledge about design patterns related to dependency injection have resulted in some bad dependency injection design practices.

• 9/14/2012 Dutch Symfony Usergroup Meetup, Utrecht (NL) website