Grundlagen

1. Einführung

Das vorliegende Framework versteht sich als Hilfsmittel für die Implementierung von objektorientierten, generischen und wiederverwendbaren PHP-Applikationen. Es werden eine Reihe von wichtigen OO-Design-Pattern implementiert und das Framework bietet Lösungen für bekannte Problemstellungen.

Es versteht sich daher bewusst als Programmier-Hilfe und nicht als fertige Anwendung, die lediglich konfiguriert werden muss. Das Software-Design kann nur vom Entwickler kommen, das Framework kann den Entwickler nur bei der Implementierung unterstützen!

2. Aufbau und Bedeutung der Ordner-Struktur

Wie in der objektorientierten Welt üblich, sind die Komponenten des Frameworks in einer nach Abhängigkeit und Bedeutung strukturierten Ordnern untergebracht. Hier bei definiert der Ordnername das Paket und der Dateiname den Namen der Klasse. Die relevanten Dateien können innerhalb von Programmteilen mit der Funktion import() eingebunden werden.

In den Release-Paketen sind folgende Ordner-Strukturen enthalten:

Code
apps/ (Verzeichnis alle Quellcode-Dateien) [config/ (Verzeichnis für Konfigurationsdateien)] core/ (Verzeichnis für die Core-Komponenten) benchmark/ configuration/ database/ errorhandler/ filesystem/ filter/ frontcontroller/ logging/ pagecontroller/ service/ session/ singleton/ modules/ (Verzeichnis für die Module) comments/ guestbook/ kontakt4/ pager/ socialbookmark/ [sites/ (z.B. Verzeichnis für Webseiten-Dateien)] tools/ (Verzeichnis für die Tools-Komponenten) cache/ datetime/ form/ taglib/ html/ taglib/ image/ link/ mail/ string/ validator/ variablen/

Die Ordner core und tools beinhalten die Kern-Bestandteile des Frameworks und werden mit jedem Release ausgeliefert. Darin befinden sich u.a. die Implementierung des Page-Controllers (/apps/core/pagecontroller/), des ConfigurationManager (/apps/core/configuration/) oder Tools wie ein ImageManager (/apps/tools/image/) bzw. der LinkGenerator (/apps/tools/link/).

Der Ordner modules beinhaltet Module, die auf den core- und tools-Komponenten aufsetzen. Dazu zählen ein Gästebuch und ein Kontaktformular, das in von Ihnen implementierte Webseiten oder Web-Applikation eingebaut werden kann.

Unterhalb von config werden Konfigurationsdateien abgelegt, die in den unterschiedlichen Teilen der Software zum Einsatz kommen. Unter Konfigurationsdateien fallen Sprachdateien, Parameterdefinitionen für Applikationen oder auch MySQL-Statement-Dateien.

Da es ein Punkt des Codexes des Frameworks ist möglichst immer wiederverwendbare Code-Teile zu erstellen, wird zwischen den Ordnern modules und sites unterschieden. Der Ordner modules beinhaltet über alle sites hinweg einsetzbare Software-Teile, der Ordner sites die eigentlichen Webseiten-Projekte. Als ein Webseiten-Projekt wird nicht nur eine Ausgabe-Seite angesehen, sondern z.B. auch ein Backend (CMS).

Die API-Dokumentation beschreibt die Inhalte der Ordner nochmals genauer.

3. Aufbau einer einfachen Applikation

Das Framework arbeitet im sogenannten "Postback"-Modus. Das bedeutet, dass ein Webseiten-Projekt in der Regel eine zentrale Datei (meist index.php, da diese im Webserver als DirectoryIndex konfiguriert ist) besitzt und über diese alle Anfragen abgewickelt werden. Ist dieses Verhalten nicht gewünscht, können auch weitere Dateien gemäß ihren Aufgaben definiert werden. Es hat sich jedoch als praktikabel erwiesen, mit einer Bootstrap-Datei zu arbeiten, da sich dadurch der Pflegeaufwand der Code-Dateien minimiert.

Als Einstieg in das APF wird das Tutorial Download, Installation und erste Schritte empfohlen.

3.1. Aufbau einer index.php

Eine einfache Applikation besteht grundsätzlich aus einer Bootstrap-Datei und einem Master-Template. Die Bootstrap-Datei lädt das Template, erstellt daraus eine Seite, die anschließend transformiert und ausgegeben wird. Im Master-Template ist definiert, wie die Applikation aufgebaut ist und welche weiteren Templates, TagLibs oder Module inkludert werden.

Eine typische index.php enthält folgende Code-Teile:

PHP-Code
// Page-Controller einbinden (APF-Core-Library) include_once('./apps/core/pagecontroller/pagecontroller.php'); // Front-Controller einbinden import('core::frontcontroller', 'Frontcontroller'); // Front-Controller erzeugen und konfigurieren $fC = &Singleton::getInstance('Frontcontroller'); $fC->setContext('{1}'); // optional: $fC->setLanguage('{2}'); // Request-Abarbeitung starten und Ergebnis zum Client senden echo $fC->start('{3}', '{4}');

Den mit {x} gekennzeichneten Platzhaltern kommt dabei folgende Bedeutung zu:

  • {1}: Context der Applikation. Dieser wird für die Adressierung von Applikations-abhängigen Konfigurations-Dateien benötigt (siehe Konfiguration).
  • {2}: Sprache der Applikation. Dieser wird für die Adressierung von Sprach-abhängigen Elementen benötigt (siehe Standard TagLibs).
  • {3}: Namespace zum Basis-Template. Um ein Design laden zu können sind die Angaben "Namespace" bzw. "Pfad" notwendig.
  • {4}: Name des Basis-Templates. Dieser Parameter beinhaltet den Name des Basis-Templates ohne dessen Endung.

3.2. Aufbau des Basis-Templates

Templates spielen im Adventure PHP Framework eine entscheidende Rolle. Abstrakter betrachtet ist dabei ein Baum-Knoten einer Webseite eine kleine MVC-Einheit, die aus einem Model (zumeist dem Model der Applikation oder Webseite), dem View(-Template), einem XML-/HTML-Template, und einem Controller (Document-Controller), falls erwünscht, besteht. Den Kern des Frameworks stellt der Page-Controller dar, der aus einem Template einen Objektbaum erzeugt und dafür sorgt, dass bei der Transformation die entsprechenden Controller ausgeführt werden.

Mit der Gestaltung der Templates definiert der Entwickler quasi die Komplexität der Seite und den Aufbau des Objektbaums. In der index.php wird mit der Methode loadDesign() ein initiales Template einer Applikation oder eines Modules geladen, das die oberste Ebene des Aufbaus der Seite definiert. Jedes eingebundene Template bildet dabei einen Kind des aktuellen Baum-Knotens. Die Verschachtelungstiefe ist dabei nicht beschränkt. Die folgende Codebox zeigt ein einfaches Template, das als Layout einer Webseite dienen kann:

Html-Code
<html> <head> <title>...</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> </head> <body> ... </body> </html>

Weiterführende Beispiele zu Templates können den Kapiteln Hallo Welt! und Templates entnommen werden, das Tutorial Erstellen einer Webseite gibt eine weitere Einführung in das Erstellen von Web-Seiten und -Applikationen.

3.3. Basis-Konfiguration

Im Gegensatz zu früheren Versionen (< 1.7) benötigt das Framework zunächst keine weitere Konfiguration. Intern werden jedoch einige Basis-Konfigurationsparameter im Namespace apf::core der Registry verwaltet. Müssen diese für den speziellen Anwendungsfall angepasst werden, so kann das in der Boostrap-Datei wie nachfolgend dargestellt bewerkstelligt werden. Die Registry dient nicht nur als zentraler Informationspool für das Framework, sondern kann auch für die Steuerung von konkreten Anwendungen eingesetzt werden.

PHP-Code
// Page-Controller einbinden (APF-Core-Library) include_once('./apps/core/pagecontroller/pagecontroller.php'); // Front-Controller einbinden import('core::frontcontroller', 'Frontcontroller'); // Umgebungsvariable manipulieren Registry::register('apf::core','Environment','MY_ENV'); // Basis-Pfad der Applikation manipulieren Registry::register('apf::core','URLBasePath','http://mybaseurl.de'); // URLRewriting-Modus ändern (true: URL wird mit / dargestellt, false: "normale" URLs) Registry::register('apf::core','URLRewriting',true); // Log-Verzeichnis anpassen Registry::register('apf::core','LogDir','/Pfad/zu/meinem/Log/Verzeichnis'); // Front-Controller erzeugen und konfigurieren $fC = &Singleton::getInstance('Frontcontroller'); $fC->setContext('{1}'); // optional: $fC->setLanguage('{2}'); // Request-Abarbeitung starten und Ergebnis zum Client senden echo $fC->start('{3}', '{4}');

Die aufgeführten Parameter der Registry haben folgende Bedeutung:

3.3.1. Environment

Verwendet von: ConfigurationManager, MySQLxHandler, MySQLHandler, SQLiteHandler, ...

Jede Konfigurations-Datei besteht aus vier unterschiedlichen Bestandteilen:

  • Namespace: Ordner, unterhalb dem alle Konfigurationsdateien dieser Anwendung liegen
  • Context: Aktueller Context der Applikation
  • Umgebung: z.B. für Entwicklung, Test und Live
  • Dateinamen: Dateiname der Konfigurationsdatei

Diese Abstraktion wurde eingeführt, damit eine Anwendung oder ein Modul in unterschiedliche andere Anwendungen oder Module eingebunden werden kann und auf unterschiedlichen Systemen zur gleichen Zeit ohne Änderung des Quellcodes lauffähig ist. Für das Laden von Konfigurationen gibt es jedoch standardisierte Methoden, so dass sich der Programmierer darum nicht mehr kümmern muss. Weiterführendes dazu kann im Kapitel Konfiguration nachgelesen werden.

Standard-Wert: "DEFAULT"

3.3.2. URLBasePath

Verwendet von: AdvancedBBCodeParser, SocialBookmarkManager, ...

Viele Module verlinken auf sich selbst oder ander Bereiche eines Moduls oder einer Webseite. Aus diesem Grund muss bekannt sein, wie die Basis-URL der Seite lautet. Der Registry-Wert URLBasePath definiert diese.

Standard-Wert: "HTTP_HOST-Wert des $_SERVER-Arrays"

3.3.3. URLRewriting

Verwendet von: ChainedGenericInputFilter, ChainedGenericOutputFilter, LinkGenerator, ...

Die mit dem APF ausgelieferten Filter und der LinkGenerator unterstützen URL-Rewriting. Unter URL-Rewriting versteht sich die Verwendung von URLs der Form http://www.domain.tld/param1/value1/param2/value2 statt http://www.domain.tld?param1=value1&param2=value2. Ist der Wert auf "true" gesetzt, so werden die mit dem LinkGenerator generierten Links in der umgeschriebenen Form ausgegeben.

Details können dem Kapitel URL-Rewriting bzw. Filter und Links entnommen werden.

Standard-Wert: "false"

3.3.4. LogDir

Verwendet von: Logger, ...

Um zentrales Logging zu ermöglichen, muss der Pfad, in den Log-Dateien geschreiben werden zentral bekannt gegeben werden. Der Pfad wird von der Klasse Logger verwendet.

Standard-Wert: "./logs"

3.3.5. LibPath

Verwendet von: div. Extensions, ...

Die Direktive LibPath speichert den Basis-Pfad, in dem die Programmdateien abgelegt wurden. Der Pfad wird dynamisch gesetzt und ist nur für den lesenden Zugriff freigegeben.

Kommentare

Möchten Sie den Artikel eine Anmerkung hinzufügen, oder haben Sie ergänzende Hinweise? Dann können Sie diese hier einfügen. Die bereits verfassten Anmerkungen und Kommentare finden Sie in der untenstehenden Liste.
« 1   »
Einträge/Seite: | 5 | 10 | 15 | 20 |
1
Christian 06.07.2008, 23:09:45
Hinweis zum letzten Kommentar:
Seit Release 1.7-beta wird das URL-Rewriting über den Registry-Wert "URLRewriting" im Namespace "apf::core" konfiguriert (siehe oben).
2
Markus Köhler 02.09.2007, 13:32:12
Nachtrag zur Konstante APPS__URL_REWRITING:
Diese wird ebenso für den frontcontrollerLinkHandler verwendet um zu unterscheiden, ob dieser im URL-Rewriting-Modus arbeitet, oder nicht.