Pipeline Architektur (1)

Wie soll das Framework aufgebaut sein, auf dem meine zukünftigen Webanwendungen basieren? Beginnen wir mit Grundüberlegungen zur Architektur.

Contentmodule
HTML/WAP/XML-Dateien, die von einer Webapplikation ausgeliefert werden, bestehen in der Regel aus verschiedenen Contentbereichen. Bei einer klassischen Webanwendung sind dies z.B. Header, Navigation, ein oder mehrere Contentbereiche und ein Footer. Diese Contentmodule können je nach Context sehr verschieden sein. Die Navigation kann zum Beispiel auf jeder Seite gleich sein, sich aber andererseits je nach Benutzerrolle unterscheiden. Eingeloggte Besucher können auf derselben Seite andere Informationen zu sehen bekommen als Gäste, usw.

Ablaufsteuerung
Es ist also sinnvoll einen Mechanismus zu haben, der auf der Basis eines Seitenaufrufs und weiteren Parametern dynamisch die Erzeugung der Contentmodule steuert. Diesen Mechanismus nenne ich Pipeline. Der Request wird “oben hineingeworfen” und “unten” kommen die Daten für die Erzeugung der Ausgabseite heraus. Das Erzeugen der eigentlichen HTML/XML/WAP- oder sonstigen Ausgabe auf der Basis der Erzeugten Daten geschieht danach mittels Templates. Die Steueranweisungen werden der Pipeline mittels einer einfachen XML-Datei übermittelt.

Views
Die Pipeline kümmert sich um den Request-Kontext und stellt dabei ein Datenrepository zur Verfügung, in das Pipeline und Contentmodule schreiben und aus dem sie lesen können. Dieses Datenrepository wird im Anschluß dem Template übergeben.

Neben dem Request Kontext gibt es noch einen Sessionkontext, der mehrere Requests eines Nutzers zusammenfasst und einen Applikationskontext, der wiederum alle Sessions zusammenfasst. Somit ergeben sich für das Framework vier Basisklassen:

• Application
• Session
• Pipeline
• Template

Deren Methoden und Eigenschaften werde ich demnächst näher beschreiben.