Mittwoch, 14. Januar 2009

Präsentieren ist Arbeiten mit Schablonen

Der Online-Buchhändler amazon.com — eine Ikone des Internet-Erfolgs — verwendet für seinen Webauftritt das Perl-basierte Framework Mason. Mason ist ein effizientes Framework zur dynamischen Webseitengestaltung vom Typ der Server Pages: Es ähnelt den Active Server Pages von Microsoft, den Business Server Pages von SAP, den Java Server Pages von Sun. Man könnte Mason als Perl Server Pages bezeichnen, wenn das Akronym PSP nicht bereits anderweitig belegt wäre. Mason-Seiten bestehen im wesentlichen aus HTML-Code, Scripting-Anweisungen und Aufrufen anderer Mason-Seiten. Das genügt zur Erstellung einer hochverfügbaren, hoch performanten Webanwendung wie amazon.com!

Jede Spielart der Server Pages, ja jedes Framework zur dynamischen Webseitengestaltung reduziert sich im Kern auf den Interpolation genannten Mechanismus, in einem gegebenen String benannte Variablen durch ihren Inhalt zu ersetzen. In der Programmiersprache Perl ist dieser Mechanismus, da er als so eminent wichtig für alle Präsentationslogik erkannt wurde, bereits in den Sprachkern eingebaut.

Betrachten wir zum Beispiel das folgende Listing:
my $button = <<BUTTON;
<table id="Btn_$fcode" class="vButton" onclick="handle('$fcode');">
<tr>
<td nowrap>
<span><img src="$root/vbutton.gif"></span><br>
<span id="$fcode\_text" class="vButtonText">$text</span>
</td>
</tr>
</table>
BUTTON

Hier wird der HTML-Code für einen Button erzeugt und der Stringvariablen $button zugewiesen. Der HTML-Code wird als sogenanntes Hier-Dokument einfach im Programm erklärt (er könnte natürlich auch von einer anderen Quelle eingelesen werden). Das Besondere ist, dass die im String enthaltenen Variablen wie $fcode und $text zur Laufzeit durch deren Werte ersetzt werden, und zwar automatisch bei der Ausführung der Zuweisungsoperation an $button. Das ist Interpolation.

Ein solches Hier-Dokument ist von einer Server Page nicht mehr weit entfernt. Interpolation ist die zentrale Aufgabe jedes Webanwendungsframeworks. Mit einem Framework, das interpolieren kann, kann man dynamische HTML-Dokumentteile erzeugen. Die Vorlagen, die statische und variable, erst zur Laufzeit zu interpolierende Teile des HTML-Resultatbaums enthalten (wie die rechte Seite der obigen Perl-Zuweisung), sind die Views der Anwendung, die zusammen deren Präsentierungsschicht ausmachen.

In einer Anwendung gibt es wiederkehrende Bestandteile. Beispielsweise sollen Buttons an verschiedenen Stellen der Anwendung erscheinen und immer gleich aussehen, jedoch unterschiedliche Funktionscodes und unterschiedliche Texte haben, was das Template aus obigem Perl-Listing motiviert. Solche Templates können beispielsweise in den verschiedenen Geschmacksrichtungen der Server Pages als Tags implementiert werden. In Rich Client Anwendungen entsprechen sie den Widgets. Sie sind gewissermassen die Elemente, aus denen die komplexeren Views zusammengesetzt werden. Und auch diese Elemente basieren bereits auf Interpolation: Sie sind parametrisierbar und mischen die Aktualwerte der Parameter in eine Schablone ein.

Die nächstgrössere Einheit sind Bildbereiche der Anwendung. Ein Bildbereich könnte z.B. aus einer Gruppe von Eingabefeldern, einigen Buttons und einem Listcontainer zur Ausgabe von Daten bestehen. Auch diese Bildbereiche müssen wiederverwendbar sein, damit sie in verschiedenen Umfeldern aufrufbar sind. Nicht nur reduziert sich dadurch der für die Präsentierung benötigte Code, sondern es tut der Anwendung auch gut, wenn gleiche Bildbereiche auch gleich dargestellt werden: Nicht nur graphische Eigenschaften wie Farben oder Rahmen, sondern auch die Reihenfolge und relative Position der Eingabefelder bleiben gleich. Auch wenn zwei Bildbereiche nur in annähernd gleicher Form benötigt werden, lohnt es sich meist, sie aus dem umgebenden Bild zu extrahieren und je nach Kontext unterschiedlich parametrisiert aufzurufen. Solche Bildbereiche können schliesslich zu den vollständigen Bildern der Anwendung zusammengesetzt werden.

Bei Aufruf eines Bildbereichs steht im rufenden View steht nur noch ein parametrisierter Aufruf, zum Beispiel der folgende mit einer fiktiven Perl-artigen Syntax:
<% call_view( 'results.htm', 
{ debitor => $customer, doc => $salesdoc } ); %>


All dies lässt sich auf beliebige Präsentationslayer verallgemeinern. Man kann ganz allgemein sagen, dass die Präsentation von Daten für einen menschlichen Benutzer im wesentlichen gleichbedeutend mit dem Ausfüllen von geeigneten Schablonen ist. Einige Beispiele:

  • Ein Kaufvertragsformular kann als ein pdf-Dokument vorgestellt werden, von dem gewisse Teile dynamisch durch die Anwendung gegeben sind - wie die Kaufvertragsnummer, der Sachbearbeiter, Name, Nummer und Anschrift des Kunden, die gewünschten Artikel, die Liefer- und Rechnungsanschrift usw. Andere Teile sind statisch und bleiben - vielleicht nicht für immer, aber wenigstens für längere Zeit - gleich: Die Texte, die Allgemeinen Geschäftsbedingungen, das Firmenlogo, insbesondere aber auch der Aufbau des Formulars (das Layout), die verwendeten Schriftarten, Zeilenabstände usw. Im SAP-System steuert ein Druckprogramm als Controller die Ausgabe eines SmartForms- oder SAPScript-Formulars. Das Druckprogramm liest die Daten des Anwendungsbelegs ein und ruft dann das Formular selbst auf, das hier als Template fungiert.

  • Die Listausgabe eines Programms reichert die in Form einer internen Tabelle gegebenen Rohdaten um Präsentierungsinformation an. Die Präsentierungsinformation – in Form von Layoutdaten und eines Feldkatalogs – gibt an, welche Spalten der Tabelle mit welcher Breite und welcher Überschrift angezeigt werden sollen, sie ermöglicht eine Anreicherung der Darstellung mit Hotspot-Links, Ikonen, Summenzeilen für bestimmte Felder, Sortierung und vieles mehr. Der ABAP List Viewer ist der Prozessor, der diese beiden Teile – die Rohdaten in Form einer internen Tabelle und die Aufbereitungsdaten (Feldkatalog, Layout) – zusammenführt.
  • In einer Webanwendung erlaubt es der CSS-Stylesheet-Mechanismus, die Präsentierungsinformationen physisch vom Content zu trennen. Zur Laufzeit wird ein HTML-Dokument fast ohne jede Präsentierungsinformation gesendet, jedoch mit einem Verweis auf eine CSS-Ressource. Diese wird vom Browser eingelesen und vorgehalten, um das gesendete HTML-Dokument für die Darstellung anzureichern.
  • Diese Idee ist mit XML/XSLT weitergetrieben. Eine XSLT-Transformation ist nichts anderes als ein Programm zur Schablonenverarbeitung: Es enthält feste Bestandteile, die identisch in den Resultatbaum übernommen werden, und variable Teile, die aus dem XML-Quelldokument extrahiert werden. Dies reduziert die zur Laufzeit zwischen Client und Server gesendeten Daten fast auf die reinen Rohdaten. Ein Overhead ergibt sich nur durch die XML-Dokumentstruktur, die aber nötig ist, um den gezielten Zugriff der XSLT-Transformation zu ermöglichen.


Die Schablone ermöglicht die Separation of Concerns, indem sie selbst im Präsentationslayer beheimatet ist, aber mit einem Mechanismus wie XSLT mit Rohdaten der Anwendung ausgefüllt werden kann.
Ein Anwendungsframework muss, wie oben beschrieben, nicht wesentlich mehr bieten als einen solchen Ausfüllmechanismus:

  • Sie kann vordefinierte Schablonen für elementare Viewbestandteile (Widgets) anbieten.
  • Sie kann die Möglichkeit für die Erstellung eigener Widgets vorsehen (Tag Libraries).
  • Sie muss die Möglichkeit vorsehen, von einem View aus einen anderen Viewteil aufzurufen.
  • Die gesamte Präsentation sollte in ein MVC-Framework eingebettet sein, so dass Controller die übergreifenden Views aufrufen können, während die Geschäftslogik in den Models beheimatet ist.

Das genügt. Über diese Anforderungen hinaus sollte ein sinnvolles Framework allenfalls eine Sammlung von Tools darstellen, indem es Utility-Funktionen für häufig verwendete Aufgaben bereitstellt.

Die Zielsprache einer Webanwendung ist in der Regel HTML. Hier liegt ein Satz von elementaren Viewbestandteilen bereits vor, was die Aufgaben eines Frameworks bereits reduziert: Beispielsweise existiert ja schon ein Eingabefeld in Form eines <input>-Elements und sollte auch so vom Anwendungsentwickler benutzt werden dürfen. Es ist nicht nötig, eine Metasprache zur Auszeichnung zu erfinden, wenn eine kanonische Standardauszeichnungssprache wie HTML bereits vorliegt. Damit eine Anwendung effizient entwickelt werden kann und neueste Features der Präsentierung beispielsweise mit HTML, JavaScript und CSS genutzt werden können, ist die Hoheit über den gesamten Code für ein Webanwendungsframework oberstes Gebot.

Keine Kommentare :