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 {% %}). 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