Manual - Bootstrap and Load order

Last updated: 2014-02-01

.htacess

Take a look at the .htaccess file

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?params=$1 [L,QSA]

What it does is to check if the file requested exists, if it exists it is served normally, and if not the bootstrap takes the action.
So if you request an image or a javascript or a stand alone php file that exists in the server, it will be delivered normally.
Otherwise the action will be transferred to the Catalonia Framework, concretely to index.php.
That gives a lot of flexibility and Freedom and allows the developer to decide where he wants to server contents by normal Apache mechanisms or by the Framework.

Understanding index.php

index.php is very clean:

<?php
use CataloniaFramework\Views as Views;
use CataloniaFramework\Core as Core;
use CataloniaFramework\Navigation as Navigation;

try {
    $i_start_time = microtime(true);

    require_once '../catfwcore/bootstrap.php';

    if (Navigation::isURLCustom(REQUESTED_PATH)) {
        // custom url
        $s_html = $o_controller->$s_action(REQUESTED_PATH, $o_db);
    } else {
        // MVC pattern
        $s_html = $o_controller->$s_action(REQUESTED_PATH, $st_params, $st_params_url, $o_db);
    }

    Views::replaceUserVars($s_html);
    // Finish time after user work
    $i_finish_time = microtime(true);
    $i_execution_time = $i_finish_time-$i_start_time;
    Views::addSystemVar('EXECUTION_TIME', $i_execution_time, Views::VAR_ACTION_REPLACE);
    // TODO: SetSystemvar finish time
    Views::replaceSystemVars($s_html);

} catch (DatabaseConnectionError $e) {
    // Todo: Check if in Json...
    // Error with Databases
    $s_html = getErrorView(Views::ERROR_EXCEPTION_ERROR, Views::$st_ERROR_MESSAGES[Views::ERROR_EXCEPTION_ERROR].' '.$e->getMessage());
} catch (CustomFileNotFound $e) {
    $s_html = getErrorView(Views::ERROR_EXCEPTION_ERROR, Views::$st_ERROR_MESSAGES[Views::ERROR_EXCEPTION_ERROR].' '.$e->getMessage());
} catch (CustomFileNotDefined $e) {
    $s_html = getErrorView(Views::ERROR_EXCEPTION_ERROR, Views::$st_ERROR_MESSAGES[Views::ERROR_EXCEPTION_ERROR].' '.$e->getMessage());
} catch (CurrencyNotFoundException $e) {
    $s_html = getErrorView(Views::ERROR_EXCEPTION_ERROR, Views::$st_ERROR_MESSAGES[Views::ERROR_EXCEPTION_ERROR].' '.$e->getMessage());
} catch (exception $e) {
    $s_html = getErrorView(Views::ERROR_EXCEPTION_ERROR, Views::$st_ERROR_MESSAGES[Views::ERROR_EXCEPTION_ERROR].' '.$e->getMessage());
}

// Echo page or error
echo $s_html;

Core::end();

Load order

As you've seen the first to be loaded is:

require_once '../catfwcore/bootstrap.php';
require_once CUSTOM_INIT_ROOT.'bootstrap.php';

The first thing to be loaded is the Framework's Bootstrap, it loads all the core classes needed, at a early stage it loads:

init/customprebootstrap.php

This is a custom bootstrap from the developer that loads at the very beginning part of the boostraping.
The goal of this file is to provide a place to define Classes, database objects, constants, third party libraries, require additional files... that will be needed later by the custom code.
The bootrap initialises everything, and then loads:

init/commonrequests.class.php

commonrequests.class.php is the place where the developer adds its custom code to be run in every requests.
The order of calls is:

1. Bootstrap loads all the required core files
2. Variables $s_params, $st_params and constant REQUESTED_PATH are defined.
3. init/customprebootstrap.php is invoked
4. CommonRequests::initSession($o_db);
   
5. CommonRequests::registerURLS(); to define user custom hardcoded URLs
6. Constants like USER_LANGUAGE, CONTROLLER, ACTION are set, so they can be readed allover the code
7. Parameters are copied into pairs for more easy use in $st_params_url
8. CommonRequests::registerUserVars($o_db); is invoked
9. CommonRequests::logRequest($o_db); is invoked
10. init/custompostbootstrap.php is invoked

The purpose of the init/ directory is that the developer does his changes here, and so when the Catalonia Framework is updated, there are no conflicts with the existing developer's code projects and Core files.
The framework provides an autoload for lazyloading classes, so if an unknown Class is invoked it will try to load from the classes/ directory.

Back to Main Manual page