Review: start building the MVC-based framework - PHP

In case you still haven’t had the chance to read the preceding part of this series, which covered the creation of the base “.htaccess” file and the framework’s front controller, below I reintroduced the definitions of these files.

Having said that, first here’s the signature of the “.htaccess” file, which is charged with redirecting all of HTTP requests straight to “index.php”:

# Turn on URL rewriting engine

RewriteEngine On

# Disable rewriting for existing files or directories

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

# redirect all other requests to index.php

RewriteRule ^.*$ index.php [PT,L]

As I said a moment ago, this file includes the minimal settings required for centralizing user requests through a single file, and nothing else. Of course, it’s possible to add to it more directives in accordance with specific needs, but for this project I’ll keep this file basic. To make this file work, you should make sure that the mod_rewrite module has been enabled on your Apache web server, and that it supports “.htaccess” files in the directory under which the framework will live.

Have you already done this? Great. It’s time to show the definition of the “index.php” file, which  acts like the framework’s front controller:

<?php

// framework’s front controller

// specify parameters for autoloading classes

spl_autoload_register(NULL, FALSE);

spl_autoload_extensions('.php');

spl_autoload_register(array('Autoloader', 'load'));

// define custom ClassNotFoundException exception class

class ClassNotFoundException extends Exception{}

// define Autoloader class

class Autoloader

{

                // attempt to autoload a specified class

                public static function load($class)

                {

                                if (class_exists($class, FALSE))

                                {

                                                return;

                                }

                                $file = $class . '.php';

                                if (!file_exists($file))

                                {

                                                eval('class ' . $class . '{}');

                                                throw new Exception('File ' . $file . ' not found.');

                                }

                                require_once($file);

                                unset($file);

                                if (!class_exists($class, FALSE))

                                {

                                                eval('class ' . $class . '{}');

                                                throw new ClassNotFoundException('Class ' . $class . ' not found.');

                                }

                }

}

// handle request and dispatch it to the appropriate controller

try{

                Dispatcher::dispatch();

}

catch (ClassNotFoundException $e){

                echo $e->getMessage();

                exit();

}

catch (Exception $e){

                echo $e->getMessage();

                exit();

}// End front controller

From the source code of the above file, it’s easy to follow all the tasks that it performs. It starts by registering via the “spl_autoload_register()” PHP function the callback method that will be invoked when autoloading classes, then it defines a custom exception class that extends the default Exception class, and finally it  finishes its execution, including the autoloader and the dispatcher classes within a “try-catch” block. That’s about it.

Due to the simple logic implemented by the pertinent “Autoloader” class, I’m not going to waste your time explaining once again how it works. Instead, I’d like you to focus your attention for a moment on the following line within “index.php”:

Dispatcher::dispatch();

Here, it’s clear to see that this line is statically calling a “dispatch()” method that belongs to a class called “Dispatcher.” As its name suggests, this class will be responsible for dissecting in pieces the requested URL and routing the request to the proper method of the matched controller, if there are any available.

However, the definition of this router/dispatcher class hasn’t been shown so far. It's time to start coding it, so you can quickly understand its driving logic. I will discuss building that class in the next section, so click on the link below and keep reading.