If you have the time, I highly recommend you work through all of the lessons in their original form. With that said, this post aims to provide a summary of what you’ll learn in each section, as well as a link to the completed code after each exercise. This will make it a breeze for you to work out what parts of Fabien’s original 12-part series are relevant to you without having to work through all of them.
I’ve created a repository on GitHub that contains the code used throughout the tutorial, tagged at the end of each exercise. This post will cover the first 6 of the lessons, and will be followed by another post summarising the last 6. So, let’s get started!
Part 1 – Installing Composer for Package Management
In the first lesson, we set-up the folder for our new web framework which we’ve named Simplex. We’re using a package manager named Composer, which will help us to define and manage the dependencies of our framework. Because we’re going to be building on-top of the Symfony 2 core components, this is handy as Composer will enable us to easily manage which versions of the third-party libraries our framework is compatible with.
The two key tasks in this lesson are: to install the Composer library and to create our manifest file, ‘composer.json,’ which is where we’ll manage library dependencies. The manifest file for Part 1 (obviously as our framework expands, so will its dependencies) can be seen below:
Part 2 – Using the HTTP Foundation classes
The basic model of a web application can be stated as: a system that maps “requests” to “responses.” In any object oriented design for such a system it would make sense to define objects that represent these “Request” and “Response” types, but in PHP this is not the case. The Symfony 2 HTTP Foundation component alleviates this shortcoming by providing an object oriented abstraction layer over the HTTP protocol.
Using this library, we can manipulate HTTP Requests and Responses as such:
This introduces interesting possibilities, such as giving us the ability to “mock” HTTP interactions for testing purposes.
Part 3 – Utilising the “Front Controller” design pattern
When designing web applications, typically we want to be able to handle requests for resources internally instead of letting the web server decide what to do with requests for different URLs. The front controller design pattern enables us to do this by providing a single entry-point for all requests throughout our application.
The first step in implementing a front controller is to separate our application into different folders. For Simplex, we’re going to use the following folder structure:
- src/ : this is where the source code for our application will go (NOT publicly accessible)
- vendor/ : any third-party libraries
- web/ : the web folder will be used to house anything that needs to be accessible from the web server, including assets and our front controller
Our front controller, named “front.php”, contains the following:
Part 4 – Mapping URLs with the Symfony 2 Routing component
In the current version of Simplex, handling URLs is very messy. We can tidy this up significantly by using the Symfony 2 Routing component which provides a set of powerful tools for mapping URLs to functionality within our application.
We can define routes and then test the current Request to see if it matches any as follows:
Part 5 – Introducing Controllers
Including a different file based on the request URL to implement the control and business logic of our application works for smaller projects. As our application expands, however, it becomes messy and the need for a more elegant solution arises. We can achieve this by using programming constructs (functions or methods) to execute the behaviour instead of doing it directly in a PHP file. The HTTP Routing class used in Part 4 can enable us to do this:
At the end of Part 5 a new application is introduced that will be used throughout the remainder of the tutorial.
Part 6 – Using The HTTP Kernel Component
In Part 6 we introduce the Symfony 2 HTTP Kernel into Simplex as a dependency. The Kernel gives us access to a range of functionality, including easy lazy-loading for Controllers, a pre-rolled framework interface, build-in events raised at useful points throughout the standard request processing lifecycle and much more. We could implement these features ourselves, of course, but why re-invent the wheel?
Using the HTTP Kernel’s Controller Resolver, our routing code now looks like this:
Until Next Time!
That concludes the summary of the first 6 parts of Fabien’s tutorial on building your own framework. Stay tuned for the next part in this series.