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.

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.

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.

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).

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.

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.

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.

• 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.

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.

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.