2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...

typspezifische Dateneingabe zuständig ist 74 . Sie bestimmt in Abhängigkeit des Typs des
Publikationsobjekts, das dem Formular zugrunde liegt (@publication) , das erforderliche
Partial und lässt es über eine render-Anweisung in das Haupt-Template einbinden. Hier
wird ersichtlich, wie ein Template auf Daten zugreifen kann, die im Controller definiert
wurden: In der Controller-Action, die das Template als Request-Antwort bestimmt hat, wurde
die Instanzvariable @publication mit einem Publikations-Objekt gesetzt – entweder mit
einer aus der Datenbank gelesenen Publikation, die über das Formular editiert werden soll,
oder einem neuen, noch leeren Objekt (wenn dem PVS über das Formular eine neue
Publikation hinzugefügt werden soll). Auf diese Instanzvariable kann das Template nun
zugreifen und in unserem Falle den Publikationstyp extrahieren, für den passende
Eingabefelder bereitgestellt werden sollen.
7.3.4 Umsetzung der RIA-Modellierung
Die RIA-Modellierung für das PVS umfasste einerseits die Beschreibung zahlreicher RIA-
Features durch Zustandsmaschinen («concreteRIAFeature»s), andererseits die
Markierung von Prozesslinks als asynchronous, um asynchrone HTTP-Requests zur
Durchführung von serverseitigen Prozessen zu modellieren. Dieses Kapitel ist der
Realisierung beider Aspekte der RIA-Modellierung gewidmet. Zuvor jedoch zwei allgemeine
Bemerkungen zur Vorgehensweise bei der Implementierung der RIA-Features: Erstens wurde
JavaScript-Code, so weit es möglich war, in JavaScript-Dateien ausgelagert, um die
Templates 'sauber' zu halten. Diese js-Dateien werden je nach Bedarf in diejenigen Templates
eingebunden, in die eines oder mehrere in der Datei definierten RIA-Features integriert
werden sollen. Zweitens wurde ein relativ hoher Grad an Abwärtskompatibilität realisiert, um
das PVS auch für Benutzer verwendbar zu machen, die JavaScript in ihrem Browser
deaktiviert haben und damit auf RIA-Features verzichten müssen (bzw. wollen). Immer dann,
wenn durch ein Feature essentielle Funktionalität zur Verfügung gestellt wird, ohne die
zentrale Anwendungsfälle des PVS nicht durchgeführt werden können, wurde zusätzlich eine
Alternativlösung implementiert, über die die benötigte Funktionalität auch ohne JavaScript in
Anspruch genommen werden kann. Nur um ein einfaches Beispiel zu nennen: Der Login-
Mechanismus des PVS wird primär über einen AJAX-Request realisiert. Für Browser ohne
JavaScript-Unterstützung wird das Absenden des Login-Formulars jedoch 'altmodisch'
synchron durchgeführt.
Die Umsetzung der RIA-Zustandsmaschinen in knapper und allgemeiner Form zu
beschreiben, fällt nicht ganz leicht, da jedes RIA-Pattern Charakteristika besitzt, die sie von
anderen Patterns unterscheidet und bei der Implementierung berücksichtigt werden müssen.
Die Grundstruktur der Implementierung kann jedoch im Wesentlichen anhand des in
Abschnitt 2.3.2 dargelegten, typischen Aufbaus eines RIA-Patterns nachvollzogen werden.
Die Interaktion des Benutzers, durch die ein RIA-Feature ausgelöst wird, wird durch ein
DOM-Event-Objekt erfasst, welches seinerseits einen für dieses Ereignis registrierten
Eventhandler aktiviert. Der Handler ist eine JavaScript-Funktion, welche in der Regel für den
zweiten Bestandteil des allgemeinen RIA-Musters verantwortlich zeichnet, nämlich die als
Reaktion auf die Benutzeraktivität auszuführende Operation. Diese wird häufig, wie z.B. bei
vielen Live Validierungen, vollständig auf Clientseite durchgeführt. Manchmal werden zur
Durchführung der Operation jedoch Daten benötigt, auf die nur der Server Zugriff hat (wie
74 Die Implementierung dieser Methode erfolgte in einem sogenannten Helper-Modul. Komplexere Ruby-
Anweisungen, die in einem Template benötigt werden, werden als Methoden in solche Module ausgelagert,
um den Code eines Templates zu verschlanken und weitestgehend frei von Programmierlogik zu halten. Im
Template selbst erfolgt dann nur noch der Aufruf einer solchen ausgelagerten Methode.
89