Listing the partial source files of the framework - MySQL

Before I begin building the MySQL abstraction class mentioned in the introduction, first off it’s necessary to show the entirety of the framework’s source files created so far, so you can have at bird’s eye a more clear idea about how they interact with each other.

First, here’s the “.htaccess” file that redirects all user requests to “index.php,” which turns out to be the framework’s front controller:

(.htaccess file)

# 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]

Since this configuration file doesn’t bear any further discussion, let's move on and take a look below at the definition of “index.php,” which is the front controller:

(index.php)

<?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

As seen above, the “index.php” file performs a few useful initialization tasks, such as autoloading classes on demand, handling both default and custom exceptions, and calling the “Dispatcher” class as well. Below you'll find the definition of this latter class, which accomplishes the routing/dispatching process in a simple fashion:  

(Dispatcher.php)

<?php

class Dispatcher

{

    // dispatch request to the appropriate controller/method

    public static function dispatch()

    {

                $url = explode('/', trim($_SERVER['REQUEST_URI'], '/'));

                array_shift($url);

        // get controller name

        $controller = !empty($url[0]) ? $url[0] . 'Controller' : 'DefaultController';

        // get method name of controller

        $method = !empty($url[1]) ? $url[1] : 'index';

        // get argument passed in to the method

        $arg = !empty($url[2]) ? $url[2] : NULL;

        // create controller instance and call the specified method

                                 $cont = new $controller;

        $cont->$method($arg);

    }

}// End Dispatcher class

The rationale behind the above “Dispatcher” class is very easy to follow. The class is responsible for dissecting the requested URL into pieces to determine which controller class to instantiate and which method of that controller to call. Logically, it’s feasible to make this class much “smarter,” particularly when it comes to sanitizing URLs, but for the demonstration purposes of this series its current functionality is more than enough.

So far, so good. At this stage, you should have an excellent idea of how each of the files listed above does its business, right? Therefore, the next thing that I’m going to do will consist of adding to the framework a new class that will be tasked with abstracting accesses to MySQL databases.

To find out how this MySQL abstraction class will be developed, click on the link below and read the following segment.