Klassen

Das vorliegende Kapitel erläutert wichtige Klassen des Frameworks und definiert die Bedeutungen dieser. Es wird auf das interne Design des Frameworks eingegangen und das dort definierte DOM besprochen. Die Klassen-Definitionen können unter API-Dokumentation in den CHM-Dateien oder den HTML-ZIP-Dokumentationen eingesehen werden.


1. Basis-Klassen des Frameworks

Zu den wichtigen Klassen zählen grundsätzlich alle Klassen im Ordner "core" und dessen Unterordnern. Diese wurden im Ordner "core" strukturiert, da der Autor davon ausgeht, dass diese zum Betrieb einer Applikation - basierend auf diesem Framework - "zwingend notwendig" sind. Im Folgenden wird nun auf die wichtigsten und am häufigsten verwendete Klassen und deren Stellung eingegangen.


1.1. coreObject

Die Klasse coreObject bildet die zentrale Klasse, von der (nahezu) alle Klassen erben. Diese definiert gemeinsam genutzte Attribute und Methoden, bzw. gibt für bestimmte Implementierungen ein Interface vor. Von coreObject erben nicht nur Klassen der Präsentations-Schicht, sondern auch Klassen der Business- und Datenschicht. Das hat den Vorteil, dass viele Teile der Applikationen vereinheitlicht werden können. Die privaten Attribute definieren Grundeigenschaften eines Objekts und ermöglichen Objektbäume per Vater-Kind-Beziehungen aufzubauen. Mit den öffentlichen Methoden können die Attribute und Eigenschaften manipuliert werden. Die privaten Methoden sind Service-Methoden, die in den Implementierungen von coreObject Verwendung finden. Diese werden beispielsweise unter Konfiguration näher betrachtet.


1.2. Document

Das Document ist eine von coreObject erbende Klasse und spielt eine ähnlich zentrale Rolle - jedoch ausschließlich in der Präsentations-Schicht. Das Document implementiert eine Reihe von Parser-Methoden, die aus einem gegebenen XML-Code einen DOM-Objektbaum generieren oder aus diesem mit Hilfe der transform()-Methoden wieder HTML-Code generieren. Jede XML- TagLib erbt von Document und nutzt die Attribute und Methoden dieser Klasse. Das UML-Diagramm dazu kann der API-Dokumentation entnommen werden. Mit der Klasse Document kommt der Entwickler beim Template-Bauen zunächst nicht in Berührung, die Definition der Klasse wird jedoch beim Erstellen von eigenen TagLibs interessant, da alle verwendete Baum-Knoten nochmals von Document ableiten müssen und sich dabei weiter spezialisieren.


1.3. Page

Die Klasse Page kapselt eine komplette Webseite mit ihrer internen Baum-Struktur. Sie findet in der Index-Datei Verwendung und implementiert eine Reihe von Methoden für das URL-Rewriting.


1.4. baseController

Die Klasse baseController ist das zentrale Interface für alle DocumentController gemäß MVC-Ansatz. Sie gibt vor, welche Methoden des DocumentControllers implementiert werden müssen und welche Attribute eines Documents innerhalb des Controllers verfügbar sind. Näheres zu Controllern kann hier nachgelesen werden. Um in Dokumenten dynamische Inhalte einzufügen muss in der abgeleiteten Controller-Klasse die Methode "transformContent()" implementiert werden. Diese wird beim Transformieren eines Baum- Knotes des Objektbaums ausgeführt und anschließend in den Inhalt des Knotens implantiert. So ist es beispielweise möglich statt "Hallo Welt!" einen Text in der jeweiligen Browser-Sprache auszugeben.


1.5. Singleton

Eine sehr häufig eingesetzte Komponente ist die Singleton-Implementierung. Die im Framework enthaltene Implementierung ist eine Abstract Singleton-Klasse. Mit dieser ist es möglich beliebige Klassen als Singleton-Objekte in der Anwendung einzusetzen. Vorraussetzung ist, dass der Konstruktor keine Pflicht-Parameter erwartet. Aus Design- und Performance-Gründen werden nahezu alle Services "singleton" verwendet. Das bedeutet, dass der "Service" während eines Requests genau einmal existiert. Dieses Muster wird vor Allem in den Service-Methoden __getServiceObject() und __getAndInitServiceObject() verwendet. Eine häufig auftretender Anwendungs-Fall von Singleton ist der Einsatz des Benchmarkers.


1.6. BenchmarkTimer

Eine weitere wichtige Komponente stellt der BenchmarkTimer dar. Mit dieser ist es möglich die Ausführungszeiten der unterschiedlichen Software-Teile zu erfassen und daraus Reports zu generieren. So können Performance-Schwachpunkte ausgemacht und Ausführungszeiten gemessen werden. Details zum BenchmarkTimer können hier nachgelesen werden.


2. DOM-Objektmodell der Präsentations-Schicht

Mit dem enthaltenen PageController besitzt das Framework einen GUI-Controller, der die komplette GUI einer Seite in einem eigenen internen DOM-Objektbaum abstrahiert. Jeder Knoten wird dabei von einem Objekt, das von Document erbt, repräsentiert. So ist gemäß Composite- Pattern sichergestellt, dass der Objektbaum mit jedem beliebigen Element an jeder beliebigen Stelle erweitert werden kann. Ein Baum-Element wird dabei gemäß MVC-Pattern von einem Model, einem View und einem Controller repräsentiert. Das Model - hier spricht man von "Model" im Sinne von Applikationsinterna wie Abläufen und Statusinformationen, nicht von "Model" im Sinne eines Domänen-Objektes - steckt häufig im Controller oder einer Business-Komponente, der View wird in der vorliegenden Implementierung durch eine Template-Datei repräsentiert und der Controller ein DocumentController, der von der Klasse baseController erbt.

Der PageController besitzt die zentrale Parser-Methode __extractTagLibTags(), die beim Erzeugen eines Baum-Knoten die in der Template-Datei vorhandenen Tags ausliest und aus den bekannten XML-Tags wiederum Kinder des aktuellen Knotens erstellt. Die Funktionalität eines Knotens wird dabei von einer TagLib repräsentiert. Das ist eine Klasse, die von Document abgeleitet ist. Die Liste der "bekannten" TagLibs kann durch Hinzufügen weiterer TagLibs in einer Template- Datei ohne Eingriff in den PageController erweitert werden. Dazu gibt es bereits einen Satz von Standard-TagLibs, die unter Standard TagLibs dokumentiert sind.

Analysiert man die Templates und Controller der aktuellen Dokumentations-Webseite, ergibt sich nach dem Parsen der Templates folgende interne DOM-Objekt-Struktur:

DOM-Objektbaum Adventure PHP Framework

Die DOM-Definition des Frameworks geht davon aus, dass die Struktur einer Seite in einem Objekt der Klasse Page gekapselt wird. Aus diesem Grund bildet das Objekt der Klasse Page den Root-Knoten. Innerhalb dieses Root-Knotens wird immer ein initialer Document-Knoten mit dem in der Methode loadDesign() angegebenen Template erzeugt. Die Tags dieses Templates werden beim Laden auf bekannte TagLibs untersucht und diese werden dann als Kind-Objekte in den Baum eingehängt.

Üblicherweise werden <core:importdesign />-Tags dazu genutzt, um die in den Attributen benannten Templates als Kind-Knoten der aktuellen Baum-Struktur einzusetzen. Auf diese Weise ist es möglich, beliebig tiefe Baum-Struktur zu erzeugen und zu verwalten. Dies bietet sich vor Allem bei großen Webseiten mit vielen Views an. Details zum <core:importdesign />-Tag können der Standard TagLibs entnommen werden.


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.
Für diesen Artikel liegen aktuell keine Kommentare vor.