A lot has happened since the start of this series. I thought it would be good to take a step back and summarise what’s happened so far. We’re also at the point where we can start looking at individual modules, outside of the cycle of the framework.
We began by looking at how the framework starts up. Following the flow of content, we can summarise the sections as follows:
The framework adds four different autoload mechanisms.
The Composer Autoloader
The concatenated class file
The ad-hoc (
The Workbench class loader
The Composer autoloader includes everything specified in
composer.json (including all of the dependencies and their dependencies and so forth). The concatenated class file then reduces the I/O for frequently-loaded classes.
This is followed by the ad-hoc loader, which helps to load anything not picked up by the previous two. Finally, the workbench loader searches for
composer.json files in the
The framework has a chain of start files, which initialise the
Application class. This is a subclass of the IoC Container. It has a few initialisation methods which register a number of service providers in the container.
Application class also constructs a chain of middleware classes, which terminate in a call to
Application->handle(). This goes on to build and send the
Along the way to building the
Response, the framework introduces the concept of environments. These help to define which set of configuration settings are used. This allows for differentiation between development/staging/production/testing environments.
The framework also sets a number of paths for things like the public and storage directories.
Application registers a number of static proxy classes, called Facades. These simplify calls to other classes, by handling the initialisation and instance method dispatching transparently.
with(new Environment($resolver, $finder, $events))->make()
View::make(), and so forth.
Configuration settings are stored in a few places. First there’s the Plain Ol’ PHP files (in the
app/config directory). Then there are the
.env.*.php files, which populate the
$_ENV global array.
Configuration also exists to create aliases to frequently-used classes, such as
Illuminate\Support\Facades\App and so forth.
The framework handles a number of small (yet essential) tasks before sending the
Response. These include things like enabling HTTP method overrides (so that
_method=PUT is treated like
PUT), and dispatching post-boot event handlers.
We then continued, by further defining the roles (and composition) of the
Request is based on a symphony component, of the same name. It is tasked with interpreting and formatting the actual request data into something more friendly for the rest of the framework/application.
It introduced us to the concept of
ParameterBag classes, which Symfony defines to help work with collections of parameters.
Request also demonstrates the Open-Closed Principle, by defining a static property; which defines the name of a factory method. This lets subclasses substitute their own factory methods, the results of which are checked by the original factory method.
Router is a manger of sorts. It collates the defined routes into a
RouteCollection and dispatches requests to routes after finding the first matching
It also introduces the concept of filters, to the boot process. Filters are sets of functionality which are executed before or after routes are dispatched, and they can alter the response of routes or prevent them from being dispatched in the first place.
Route is a link between a URL pattern, one or more HTTP methods and a set of functionality (such as a route callback or Controller action).
This can be matched against the current request to select the first applicable route, which is then run. The results are given to a
Response is based on a Symfony component, of the same name. Its job is to format any return data (from filters, route callbacks, actions, what-have-you) into an acceptable response. For JSON requests (Ajax, or just the right content-type) it will return the correct content type and encode the data appropriately.
It comes in three flavours; Vanilla, Json and Redirect. While
Response will return JSON data for an explicit request,
JsonResponse will short-cut the process.
RedirectResponse just renders a small HTML document which redirects the browser.