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

Am Code für die entsprechende Action im Rails-Controller lässt sich gut erklären, welche der
Informationen, die in obigem Modellausschnitt enthalten sind, plattformspezifisch in der
Steuerungsschicht umgesetzt werden, und wie dies geschieht:
1 def show_details
2 @publication = Publication.find(params[:id])
3 render(:template => 'publications/show_details')
4 end
Mit den Schlagwörtern def und end wird in Zeile 1 und 4 die Methodendeklaration eingeleitet
bzw. beendet. Zeile 3 enthält einen abschließenden render-Befehl, mit dem die View
angewiesen wird, das Template mit dem Namen 'show_details' im (View)-Ordner
'publications' zu rendern und an den Client zu schicken. Wie bereits festgestellt, kennt Rails
keine abstrakten Navigationsknoten – im Controller wird direkt mit den View-Templates
gearbeitet, die ihre Entsprechung auf Modellebene in Elementen des Präsentationsmodells
haben. In Zeile 2 wird eine Instanzvariable (@publication) mit dem Publikations-Objekt
gesetzt, dessen Details angezeigt werden sollen. Dieses Objekt entspricht dem Eingabeobjekt,
das der Zielknoten Publication über den Navigationslink von PublicationList
erhält (d.h .dem Objekt, das an dem «index» ausgewählt wurde). Es muss mit Hilfe der
Klassenmethode find der Modell-Klasse Publication explizit aus der Datenbank
gelesen werden. Dazu bedient sich die Action der ID des betreffenden Publikationsobjekts,
die aus der URL des HTTP-Requests extrahiert wurde und im params-Objekt zu finden ist,
über das der Action die HTTP-Parameter der Anfrage zur Verfügung gestellt werden 71 . Das zu
rendernde Template hat Zugriff auf die Instanzvariable @publication, somit kann das
Template dynamisch mit den Daten der ausgewählten Publikation aufgefüllt werden. Hier
wird wiederum ersichtlich, wie Rails ohne eine abstrakte Zwischenschicht auskommt, die bei
UWE durch das Navigationsmodell gestellt wird: Während bei UWE Präsentationsgruppen
einen Navigationsknoten als Kontext besitzen, der die Daten zur Verfügung stellt, welche von
UI-Elementen der Gruppe angezeigt werden sollen, operieren Rails-Templates direkt auf
Instanzen von Inhaltsmodell-Klassen. Damit beantwortet sich auch die Frage, an welcher
Stelle einer Rails-Anwendung Navigationseigenschaften definiert werden: Genauso wie die
sie besitzenden Navigationsklassen existieren solche Konstrukte dort nicht, stattdessen
extrahiert die View die zur Anzeige bestimmten Daten direkt aus Modellobjekten.
Viele der bis jetzt in diesem Abschnitt gemachten Erläuterungen treffen auch die
Implementierung von Prozessklassen zu. Für einen einfach strukturierten Prozess wie z.B.
EditPublication im PVS, dessen Workflow-Aktivität genau eine UserAction enthält
(zur Repräsentation des Webformulars zur Angabe der Publikations-Daten), werden zwei
Controller-Aktionen benötigt. Die, die (zeitlich) zuerst aufgerufen wird, ist dafür zuständig,
das entsprechende Template zur Eingabe der Prozessdaten (also z.B. ein Webformular)
festzulegen und der View zum Rendern zu übergeben. In einem Fall wie dem Editieren einer
bereits bestehenden Publikation muss außerdem, ähnlich zum gerade diskutierten Beispiel,
das zu editierende Objekt aus der Datenbank geladen und über eine Instanzvariable dem
entsprechenden Template zugänglich gemacht werden, damit dort die Anfangswerte der
Eingabefelder in Abhängigkeit von dem betreffenden Objekt festgelegt werden können. Wenn
man die hier vorgeschlagene Übersetzungsregel 'Navigationslink – Controller-Action' auch
auf Prozessklassen und deren Einbindung in das Navigationsmodell anwenden möchte, so
71 Dieses Objekt besitzt eine Hash-Struktur, d.h. es speichert die Namen der HTTP-Parameter als Schlüssel und
die Parameterwerte als Schlüsselwerte. Wie im Code-Beispiel ersichtlich, können die Werte über die
entsprechenden Schlüssel abgerufen werden.
84