Manual - Bootstrap i l'ordre de càrrega

Darrera actualització: 2014-02-01

.htacess

Doneu-li un cop d'ull a l'arxiu .htaccess

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?params=$1 [L,QSA]
El que fan aquestes rules és revisar si l'arxiu sol·licitat existeix, i si existeix és servit pel servidor web, com sempre, i si no existeix llavors el Bootstrap pren el control.
Així que si demaneu una imatge o un arxiu javascript o un arxiu php independent que existeix al servidor, serà mostrat/executat normalment.
En un altre cas la acció petició serà transferida al Catalonia Framework, concretament a index.php.
Això proporciona molta flexibilitat i Llibertat i permet al desenvolupador decidir si vol servir els continguts pels mecanismes normals del servidor web o pel Framework.

Entenent index.php

index.php és molt net:
<?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();

Ordre de càrrega

Com veieu el primer a ser carregat és:
require_once '../catfwcore/bootstrap.php';
El primer que es carrega és el Bootstrap del Framework, aquest ho inicialitza tot, i llavors carrega:
init/commonrequests.class.php
commonrequests.class.php és l'indret on el desenvolupador afegeix els seu propi codi personalitzat, que s'executa a cada petició http.
L'ordre de les crides és:
  1. Bootstrap carrega tots els arxius del Core requerits
  2. Les variables $s_params, $st_params i la constant REQUESTED_PATH són definides.
  3. init/customprebootstrap.php és invocat
  4. CommonRequests::initSession($o_db); és
  5. CommonRequests::registerURLS(); per a definir URLs estàtiques
  6. Constants com USER_LANGUAGE, CONTROLLER, ACTION són fixades, per a que puguin ser emprades arreu del codi
  7. Els paràmeters són copiat en parells per a un fàcil ús a $st_params_url
  8. CommonRequests::registerUserVars($o_db); és invocat
  9. CommonRequests::logRequest($o_db); és invocat
  10. init/custompostbootstrap.php és invocat
Després d'això, l' init/bootstrap.php és executat. Aquest és el Bootstrap del desenvolupador. Aquí el desenvolupador pot afegir requires per a les seves classes i arxius, llibreries de tercers, etc...
L'objectiu d' init/ directory és que el desenvolupador faci els seus canvis aquí, així quan el Catalonia Framework és actualitzat amb una nova versió, no hi haurà conflictes amb el codi del projecte del desenvolupador i el codi Core del Framework.
El Framework proporciona un autoload per a "lazy loading" les classes (quan es demanen si no s'havien carregat), així si una classe desconeguda és invocada el Framework intentarà carregar-la del directori classes/.

Back to Main Manual page