|
|
|
|
Quicknavi |
|
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 Author 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-Dateien 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 ö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:
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-Seite
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.
|
|
|
|
(3.5)