When you are reading about web application development, “front controller” and “single point of entry” are frequent words you are confronted with. To my understanding, the point is to provide a single location where you decide what to do in your program. That’s all nice and well in theory, but I am confused as to how this would look in reality.
In OOP, I suppose your “controller” would commonly be instantiated in the “index.php”, or whatever file is your “entry point”. But how to go from there and how does the controller class look like? Is it something along the lines of this:
//Dummy-code, it's just to make a point
class Controller {
//first function to be called
public function main() {
switch($appAction) {
case "login": userLogin(); break;
case "view" : viewArticle(); break;
//...
}
}
protected function userLogin() {
//Sanitisation of user input
//making instances of necessary classes etc.
}
//...
}
or did I get the whole concept completely wrong? This is the only thing I can imagine to be the case, but I’m just not sure if there is a major mistake in approaching it this way or if I just misunderstood the purpose of a front controller.
PHP out of the box works like this (forgive the obviousness, but it’s an important foundation to understand):
- Client visits: example.com/about.php
- Server (usually Apache) receives this request, looks under example.com domain file structure, and in the main directory looks for “about.php”. If it is present the server executes PHP with a target of about.php.
- PHP reads the file, running the script as written.
Now, what’s wrong with this? Well, mostly nothing. But a few set of complaints began to be common.
One, how do you pass extra information to a script in the URL? Well, query strings of course…and some people found them ugly, and in wild and wooly ancient times lots of rumors abounded that URLs with query strings attached did not get properly credited – or even indexed – by search engines. Gasp!
Other people just found query strings ugly and hard to understand. But what about the internet isn’t, amiright?
Another line of problems was with “web applications”, and how most or even all pages have the same basic logic at the top. You might want to do some processing of query strings, or handle cookies, load in some template logic, etc. And that was thought to be messy to have files all around, conditional includes to keep file-sizes manageable, and so on.
In ancient times PHPophiles just had a common require() of a file that contained all this common logic. But this technique fell out of favor many years later (maybe as many as 5 years later if you can believe it), as some deemed it repetitious and old-fashioned (amongst other things).
It then came into common knowledge that you could instead use Apache to route ALL requests to a single file, and have Apache convert the extra path information in the URL and pass it as a parameter to a simple index.php file!
This basic idea, that all requests are sent to a single file instead of to individual PHP files directly, became known as a “front controller”.
My favorite framework for demonstration purposes of how these things might be handled is CodeIgniter, because it isn’t super magical or complex. Take a look at their index.php file to see how things might work.
Basically it’s just a regular PHP file, which itself defines constants that might come in handy elsewhere, (like BASEPATH and such), handles some severe unrecoverable system errors (like the whole application folder being in an unknown place!), etc. Then, once all that is done, the next file in the application is loaded, and on down the line.
With front controllers a key function is to disconnect the real system directory file structure on the server from the URL path. Where as in the old days if you had a folder in the main directory named “errata”, and a file in that named “misc-gumballs.php”, the URL to get to that file was simply “example.com/errata/misc-gumballs.php”.
With a front controller you might instead choose to have “example.com/super-delicious-free-samples/gumballs”, and using Apache and PHP you instead run a index.php file which looks in a “default” folder, loads the “classes.php” file inside of it, executes the function inside the Page class defined in that file gumballs($param = null), and passes “super-delicious-free-samples” as the value of the parameter.
Ack, History! TLDR;
A front controller is just a simple PHP file which, using something like server-side Apache routing rules, has requests funneled to it instead of to individual PHP files directly. This lets you put all your common logic in that file, and you can conditionally choose how to proceed with the request based upon the parameterized data from the requesting path.
It can be as simple as a conditional include() or require(), or it can instantiate a complex Object Oriented design. There’s really nothing magical or even especially complex about them.
Your example code is not entirely off the mark, though it is a little “public void main” for usual PHP-style coding. Most systems I’ve seen implement the functions themselves as page names, but this is not a strict requirement, and there is therefore nothing wrong – conceptually – with your example!
I think we got it.
2
Front controller is just a PHP file which dispathes requests, loads configuration, initializes autoloading mechanism, etc.
Frameworks may vary on what goes into front controller, but usually there is a set of Routes, which map request URL to a (Controller, Action) pair. For example, if URL is user/login, then UserController->loginAction() should be invoked.
As an example of such architecture, you can read Symfony docs.