Concrete5: Entwicklung mit Concrete5: Concrete's Anwendungsablauf

Zurück zu 'Coding Style Anleitung' | Hoch zu 'Inhaltsverzeichnis' | Vor zu 'Themen verstehen/erweitern'

Jede Anfrage im Concrete-System läuft über index.php im Webroot. Solange das System schicke URLs, ist Apaches mod_rewrite-Modul für das Rerouting der Aufrufe im Hintergrund verantwortlich. Index.php nimmt die gesamte Anfrage entgegen und sendet sie weiter an dispatcher.php aus dem Basis-Anwendungsverzeichnis. Dies geschieht, damit sich mehrere Concrete-Webseiten eine Dateiansammlung auf einem festgelegten Server teilen können. Die folgende Liste gibt Aufschluss über die Aktionen, die von dispatcher.php zum Behandeln von Anfragen ausgeführt werden:

Definieren von C5_EXECUTE

 define('C5_EXECUTE', true);

Mit dem Setzen dieser Konstanten wird sichergestellt, dass innerhalb von dispatcher.php agiert wird.

Startup check

 require(dirname(__FILE__) . '/startup/config_check.php');

Dies ist das erste Element im Ablauf. Damit wird überprüft, ob config/site.php verfügbar ist. Falls das der Fall ist, wird diese inkludiert. Falls nicht, wird eine Variable gesetzt, durch die Concrete erfährt, dass diese als nicht installiert erscheint. Das wird später verwendet, nachdem bestimmte Kernbibliotheken geladen wurden.

Laden der Basis Konfigurationsdatei

 require(dirname(__FILE__) . '/config/base.php');

Hier werden alle Konstanten und internen Einstellungen, die von Concrete verwendet werden, mit Pfaden geladen. Diese Datei übernimmt zudem das Inkludieren der Loader-Bibliothek, die zum Laden von Elementen von hier nach außen verwendet wird.

Aufruf von dispatcher.php sicherstellen

 require(dirname(__FILE__) . '/startup/file_access_check.php');

Um einen direkten Aufruf von dispatcher.php zu unterbinden, wird hier der Aufruf sichergestellt.

Laden der Datenbank

 Loader::database();

Concrete lädt die Datenbank (verbindet sich allerdings noch nicht) . Das geschieht durch ADODB.

Laden benötigter Bibliotheken

 Loader::library('object');
 Loader::library('log');
 Loader::library('localization');
 Loader::library('request');
 Loader::library('events');
 Loader::library('model');
 Loader::library('item_list');
 Loader::library('view');
 Loader::library('controller');
 Loader::library('file/types');
 Loader::library('block_view');
 Loader::library('block_view_template');
 Loader::library('block_controller');
 Loader::library('attribute/view');
 Loader::library('attribute/controller');

Concrete lädt nun seine eigenen Kern-Bibliotheken. In Concrete5 stellt eine Bibliothek einen Teil des Codes dar, der ohne speziell an das CMS gekoppelt zu sein, verwendet wird.

Autoload Einstellungen

 if (C5_ENVIRONMENT_ONLY == false) {
     require(dirname(__FILE__) . '/startup/autoload.php');
 }

Laden benötigter Module

 Loader::model('area');
 Loader::model('attribute/key');
 Loader::model('attribute/value');
 Loader::model('attribute/category');
 Loader::model('attribute/set');
 Loader::model('attribute/type');
 Loader::model('block');
 Loader::model('block_styles');
 Loader::model('file');
 Loader::model('file_version');
 Loader::model('block_types');
 Loader::model('collection');
 Loader::model('collection_version');
 Loader::model('config');
 Loader::model('groups');
 Loader::model('package');
 Loader::model('page');
 Loader::model('page_theme');
 Loader::model('permissions');
 Loader::model('user');
 Loader::model('userinfo');

Concrete-Ladevorgang beinhaltet die benötigten Modelle and Klassen, die für einen normalen Rendervorgang einer Seite benötigt werden. Modelle sind direkt an die Datenbank gebunden, obwohl es darüber hinaus momentan keine lexikalische Definition gibt.

Setup Timezone Support

 require(dirname(__FILE__) . '/startup/timezone.php'); // muss inkludiert werden, bevor Funktionen aufgerufen werden, die sich auf Datum Bearbeitung beziehen (php 5.3 +)

Startup Cache

 Loader::library('cache/abstract');	
 Loader::library('cache/' . CACHE_LIBRARY);	
 Cache::startup();

Startup Check, Installation

 require(dirname(__FILE__) . '/startup/magic_quotes_gpc_check.php');

Default Routen zu den unterschiedlichen Inhaltseinträgen

 require(dirname(__FILE__) . '/config/theme_paths.php');

Laden der Session Handler

 require(dirname(__FILE__) . '/startup/session.php');

Startup Check, Dekodierung

 require(dirname(__FILE__) . '/startup/encoding_check.php');

Dateitypen

 require(dirname(__FILE__) . '/config/file_types.php');

Startup Check, Konfiguration abgeschlossen

 require(dirname(__FILE__) . '/startup/config_check_complete.php');

Benutzerebene, Konfiguration

 require(dirname(__FILE__) . '/config/app.php');

Seitenebene, POST Benutzer/Anwendungen Konfiguration

 if (file_exists(DIR_BASE . '/config/site_post.php')) {
     require(DIR_BASE . '/config/site_post.php');
 }

Setzen von Debug abhängigen und aufzeichnenden Aktivitäten

 require(dirname(__FILE__) . '/startup/debug_logging.php');
 require(dirname(__FILE__) . '/startup/tools_upgrade_check.php');

Spezielle Seiten Routen für unterschiedlichen Inhaltseinträgen (falls vorhanden)

 @include('config/site_theme_paths.php');

Dieser Codeblock initialisiert interne Pfade für verschieden Themen auf der Webseite. Themenpfade routen bestimmte Themen in Kernpfaden des Concrete Dateisystem. Fehlerbehandlung wird in der zweiten Inkludierung vorgenommen, weil die Datei nicht existieren könnte. (Hinweis: das Konfigurationsverzeichnis einer Webseite existiert an zwei Stellen - einmal im Anwendungsverzeichnis ./concrete und einmal im Webroot ./)

Spezielle Seiten Routen für unterschiedlichen Dateitypen (falls vorhanden)

 @include('config/site_file_types.php');

Paketereignisse

 require(dirname(__FILE__) . '/startup/packages.php');

Inkludierungscheck

 require(dirname(__FILE__) . '/startup/tools.php');
 // Inkludierungswerkzeuge. Format: index.php?task=include_frontend&fType=TOOL&filename=test.php

Spezifische Seiten/Anwendung Ereignisse (falls definiert)

 if (defined('ENABLE_APPLICATION_EVENTS') && ENABLE_APPLICATION_EVENTS == true) {
     @include('config/site_events.php');
 }

Diese müssen vor packages.php eingebunden werden.

Benutzerbezogene Ablaufbearbeitung

 require(dirname(__FILE__) . '/startup/user.php');

Der obere Codeblock lädt eine Reihe von Subroutinen die im Startverzeichnis liegen

1. Zuerst wird die Sitzung initialisiert.
2. Als nächstes wird überprüft, ob Concrete installiert ist. Configcheckcomplete prüft die Variable, die von der am Anfang von dispatcher.php stehenden configcheck Routine gesetzt wurde. Falls Concrete keine seiner Konfigurationsdateien finden kann, sorgt configcheck_complete dafür, dass die Installationsansicht gerendert, und das Hauptprogramm verlassen wird.
3. Nachdem die Konfiguration überprüft wurde, wird eine Verbindung zur Datenbank aufgebaut.
4. Anschließend wird die SQL und Fehler Ausgabe eingerichtet. Dies geschieht getrennt vom logging - dadurch wird auch grundlegend bestimmt ob bestimmte Fehler in der Ausgabe, und dem ausführlichen Modus, alle SQL Anfragen mit angezeigt werden. Im Dashboard kann diese Option eingestellt werden.
5. Jetzt wird die Benutzer Klasse geladen. Falls ein Benutzer eingeloggt ist, werden die uLastOnline Parameter aufgefrischt.
6. Zu guter Letzt, initialisiert dieser Codeblock die “tools/” Anfragen. Werkzeuge sind statische PHP Dateien mit dem Zweck, interne Concrete Interface Funktionalität durchzuführen. Diese laufen auch durch dispatcher.php

 if (C5_ENVIRONMENT_ONLY == false) {	
     // Herausfinden wohin es geht
     $req = Request::get();
     if ($req->getRequestCollectionPath() != '') {
         $c = Page::getByPath($req->getRequestCollectionPath(), false);		
	 } else {
         $c = Page::getByID($req->getRequestCollectionID(), false);
	 }

Dieser Code löst unsere aktuelle Anfrage auf, und findet heraus, wie ein Seitenobjekt zu bekommen ist. Wird ein cID übergeben (der zu Collection/Page ID verknüpft), dann fragen wir numerisch an, indem die getById Methode der Seiten Klasse verwendet wird. Wird eine cPath Variable übergeben, wird die Seite mit Hilfe der getByPath Methode ermittelt.

	
	 if ($c->isError()) {
	     // falls ein Fehler beim Holen von Informationen über diese einzelne Sammlung auftratt, 
             // wird die Inhalt Klasse geladen
	     switch($c->getError()) {
	         case COLLECTION_NOT_FOUND:
		     $v = View::getInstance();
		     $v->render('/page_not_found');
		     break;
		 }
	 }

Die Seite wird daraufhin überprüft ob Sie einen Fehlercode zurückgegeben hat. Wenn dem so ist, was wirklich nur der Fall sein kann, wenn es die aufgerufene Seite nicht gibt, wird die "404" Ansicht gerendert. (Hinweis: diese Fehlerkonstanten sind in config/base.php definiert)

Check maintenance mode

     require(dirname(__FILE__) . '/startup/maintenance_mode_check.php');

An diesem Punkt wird überprüft, ob sich die geladene Seite im maintenance Modus befindet. Der maintenance Modus wird über das Dashboard gesteuert. Ist dieser aktiv, ist das Dashboard immer noch für Administratoren erreichbar, die Webseite ist aber nicht erreichbar.

Check externen Alias

     // Es wird überprüft, ob es sich um eine externen Alias
     // handelt. Ist dies der Fall geht es hier weiter
     include(dirname(__FILE__) . '/startup/external_link.php');

Als nächstes wird geprüft, ob die geladene Sammlung zu einem externen Link korrespondiert. Ein externer Link ist ein HTTP Link zu einer externen Resource, wie z.B. "http://www.nutzleistung.de". Durch Hinzufügen im Dashboard, sind externe Links nützlich, um externe Resourcen in die interne Navigationsstruktur einzufügen, wie z.B. die Page List und AutoNav Blöcke.

Zugriffsobjekt erhalten

     $cp = new Permissions($c);
     // Nun, da wir das Sammlungs- und Zugriffsobjekt haben,
     // überprüfen wir ob alles mit der Sammlungen und den Zugriffen OK ist
     if ($cp->isError()) {
         // falls ein Fehler aufgetreten ist, wird die Inhaltsklasse
         // geladen und 'Seitenzugriff nicht erlaubt' ausgegeben
         switch($cp->getError()) {
             case COLLECTION_FORBIDDEN:
                 $v = View::getInstance();
                 $v->setCollectionObject($c);
                 $v->render('/page_forbidden');
                 break;
         }
     }

Falls bis hier alles geklappt hat, wird versucht eine validierte Seite anzufordern. Also wird das Seitenobjekt einem Zugriffskonstruktor übergeben, der ein Zugriffsobjekt zurückgibt. Danach wird das Zugriffsobjekt auf Fehler überprüft und im Fehlerfall davon ausgegangen, dass eine Seite aufgerufen wurde für die kein Zugriffsrecht besteht. In diesem Fall wird eine 403 Ansicht gerendert, die normalerweise identischen zur Login Ansicht ist.

Zusammenfügen der Sammlung

     // Sind keine Fehler aufgetreten, wird die Sammlung hier zusammengefügt, 
     // aber erst, nachdem die zugehörige Seitenversion geladen wurde. 
     // Über zwei Klassenmethoden des Sammlungsobjekts, wird bestimmt,
     // welche Version man sieht.
     if ($cp->canWrite() || $cp->canReadVersions()) {
         $cvID = ($_REQUEST['cvID']) ? $_REQUEST['cvID'] : "RECENT";
     } else {
         $cvID = "ACTIVE";
     }
     if ($_REQUEST['ccm-disable-controls'] == true || intval($cvID) > 0) {
         $v = View::getInstance();
         $v->disableEditing();
         $v->disableLinks();
     }

In diesem Codeabschnitt wird bestimmt, ob eine bestimmte Version einer Seite geladen werden soll, und, falls dies der Fall ist, ob diese Seite editierbar ist (Editieren alter Seitenversionen ist deaktiviert.)

     $vp = $c->loadVersionObject($cvID);
     // gibt das $vp Object zurück, welches dann daraufhin überprüft wird
     if ($vp->isError()) {
         // ob ein Fehler aufgetreten ist. Dann wird die Inhaltsklasse geladen
         switch($vp->getError()) {
             case VERSION_NOT_RECENT:
             // Ist die Sammlung nicht die aktuellste Seitenversion,
             // wird das Schreiben in diese deaktiviert. 
             $cp->disableWrite();
             break;
         }
     }

Versionsverwaltung wird fortgeführt, und Editierbarkeit für alte Versionen deaktiviert.

Überprüfen transferierter Formulare

     require(dirname(__FILE__) . '/startup/process.php');

Das ist CMS spezifische Arbeit, ähnlich dem Seiten Hinzufügen. Die process.php Datei bestimmt, ob bestimmte Aktionen auf Basis von POST und REQUEST Variablen ausgeführt werden. Process.php ist die Datei die alle CMS Abläufe überwacht, die von Concrete durchgeführt werden.

Aufzeichnen der Ansicht

     if (STATISTICS_TRACK_PAGE_VIEWS == true) {
         $u->recordView($c);
     }

Dieser Codeblock nimmt die Ansicht in einer statistischen Tabelle auf.

Rendern der Ansicht

     $v = View::getInstance();
     $v->render($c);
 }

Dieser finale Abschnitt ist für das Rendern der Ansicht zuständig. Die Rendermethode ist für das Abmelden von der Datenbank genauso verantwortlich, wie für das Ausgeben von SQL Anfragen, wenn das entsprechende Debug Level gesetzt ist.

---

Zurück zu 'Coding Style Anleitung' | Hoch zu 'Inhaltsverzeichnis' | Vor zu 'Themen verstehen/erweitern'