In this final post of his series about building a framework on Symfony2 components, Fabien Potencier focuses again on flexibility - allowing you to have more than one front controller with different configurations thanks to dependency injections.

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.

The Symfony2 DIC (DependencyInjection) allows you to create a container with the objects and settings that you want and inject that into the main "Framework" class for its use. He registers most of the components he's added over the series like the UrlMatcher, RouterListener, ExceptionListener, EventDispatcher and the Framework class itself. This is all stored in a separate file(s) and can be conditionally included based on your environment. He shows how to register a custom listener, add parameters to the DIC configuration.

In part eleven of his "Build a Framework on top of Symfony2", Fabien Potencier improves on his earlier versions of the code by adding in the HttpKernel support for handling events and errors that might come up in the application.

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?

Using the "RouterListener" functionality, he sets up an "ExceptionListener" and points that to an error handling controller with its own "exceptionAction". This action takes the exception information and displays a "Something went wrong!" message along with the details. He also includes an update to the Response handling to allow for returning a string back from the controller instead of a Response object.

Fabien Potencier has posted the tenth part of his series about making a custom framework based on the Symfony2 component set. In this latest article he focuses on using the HttpKernelInterface to add in some additional HTTP-related support.

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.

By changing up the custom framework just a bit to use HttpKernelInterface, you get built-in HTTP caching (HttpCache). He shows how to use this class to create some custom caching rules and how to use Edge Side Includes to only cache partial parts of the page.

Fabien Potencier has posted the ninth part of his "build a framework on Symfony2 components series. In this latest tutorial he takes the simple framework he's already created (complete with some unit tests) and makes it easier to extend.

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.

He chooses the Observer design pattern as a basis for his example, allowing any kind of behavior/actions to be added to the framework's execution. He includes the Symfony2 dispatcher to make this work and includes the code for a "handle" method to fire off events. It executes a "ResponseEvent" every time the framework is executed. An "addListener" method provides the hook to apply a callback to an event - in his case an anonymous function (or closure).

Fabien Potencier has posted the eighth part in his "building a framework on Symfony2 components" series. So far he's created a full-featured microframework with routing, controllers, HTTP handling and namespaced code. In this latest part he improves the sample framework by adding some unit tests.

Some watchful readers pointed out some subtle but nonetheless important bugs in the framework we have built yesterday. When creating a framework, you must be sure that it behaves as advertised. If not, all the applications based on it will exhibit the same bugs. The good news is that whenever you fix a bug, you are fixing a bunch of applications too. Today's mission is to write unit tests for the framework we have created by using PHPUnit.

He includes the XML for a basic phpunit.xml configuration file and uses a UrlMatcher and ControllerResolver in a "Framework" class and makes the test check for "not found" URLs and for checking for a correct Response.

Fabien Potencier has posted the seventh part of his series looking at how to make a custom framework on top of the components from the Symfony2 framework. In this part of the series he improves his basic framework by adding some namespacing to organize the application a bit more.

If you have a closer look at the code, front.php has one input, the Request, and one output, the Response. Our framework class will follow this simple principle: the logic is about creating the Response associated with a Request. As the Symfony2 components requires PHP 5.3, let's create our very own namespace for our framework: Simplex.

He puts the main front controller in just the "Simplex" namespace but adds in others for the controllers and models. He also updates his Composer configuration to create some PSR-0 autoloading.

In the sixth part of his series on creating a custom framework on top of the Symfony2 components, Fabien Potencier looks at how to improve the previous examples by swapping out the more procedural controllers with actual classes.

The move is pretty straightforward and makes a lot of sense as soon as you create more pages but you might have noticed a non-desirable side-effect... The LeapYearController class is always instantiated, even if the requested URL does not match the leap_year route. This is bad for one main reason: performance wise, all controllers for all routes must now be instantiated for every request. It would be better if controllers were lazy-loaded so that only the controller associated with the matched route is instantiated.

To help solve the issue, he uses the HttpKernel component and its "controller resolver" to figure out how to call the controller and pass it the correct parameters, but only when needed. A resolver object is created and that is used to instantiate the controller object. Sample "action" calls are included to fill out the basic controller (his "leap year" example) and the full resulting code is included both for the framework and the new object oriented controller.

Fabien Potencier has posted the fifth part of his series looking at building a custom framework on top of the Symfony2 components. In this new tutorial he adds in one of the major features of any framework - the controller level.

For simple pages like the ones we have created so far, that's not a problem, but if you want to add more logic, you would be forced to put the logic into the template itself, which is probably not a good idea, especially if you still have the separation of concerns principle in mind. Let's separate the template code from the logic by adding a new layer: the controller: The controller mission is to generate a Response based on the information conveyed by the client Request.

He updates the template rendering to use an external method instead of doing it itself and updates the routing to include a "_controller" attribute pointing to the method. The full code for the updated version of the framework is included - a simple request/response with handling for a "leap_year" route.

Fabien Potencier has posted the third and fourth parts of his "Build a framework on top of Symfony2 components series to his blog:

• Part three adds on another page to the sample site, creating a front controller and changing the output to use "setContent()" instead of just echoing the data.
• In part four he refactors the code to be a bit more readable, adds in the Symfony2 Routing component to correctly get the requests to the right controller and an example of how to generate routes based on route definitions.

You can find the other parts of the series here: part one, part two.

Fabien Potencier is back with the next installment of his "Building a framework on top of Symfony2" tutorial series with this look at using the HttpFoundation component to use the Request and Response classes to handle HTTP interaction. (Part one is here.)

The first step towards better code is probably to use an Object-Oriented approach; that's the main goal of the Symfony2 HttpFoundation component: replacing the default PHP global variables and functions by an Object-Oriented layer.

He shows how using this component not only makes OOP handling of requests/responses simpler, but also helps to make your application more secure through features already included in the HttpFoundation component. Sample code is included showing how to fetch the current request, get filtered values from the superglobals (GET/SERVER/etc) and how to respond with a refactored version of the "Hello world" message from the previous example.