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.

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.

Fabien Potencier has written up a new post on his blog talking about creating your own framework layered on top of the Symfony2 framework's component system (yes, a framework from a framework).

Symfony2 is a reusable set of standalone, decoupled, and cohesive PHP components that solve common web development problems. Instead of using these low-level components, you can use the ready-to-be-used Symfony2 full-stack web framework, which is based on these components... or you can create your very own framework. This series is about the latter.

He talks about the reasoning behind wanting to make your own framework, mostly dealing with exploration and/or proving you can do it. He walks you through every step of the way - creating the base directory, setting up a project via Composer, creating an autoloader and making a first basic file - a "Hello world" echo message. In the next part of the series, he'll add in the HttpFoundation component for web interaction.