2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...
2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...
2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
lanciert wird. Das View-Modul von Rails bietet hierzu eine handliche Methode<br />
form_remote_tag an, die, im entsprechenden Template aufgerufen, ein geeignet<br />
modifiziertes HTML-Formular erzeugt: Durch den Methodenaufruf wird neben dem HTML-<br />
Code für das Formular automatisch Javascript-Code generiert, der das Formular mit einem<br />
Eventhandler für das 'submit'-Ereignis versieht. Im Rumpf der Eventhandler-Funktion, der<br />
ebenfalls automatisch generiert wird, wird ein AJAX-Request an die URL erzeugt, die für die<br />
Verarbeitung der Formulardaten spezifiziert wurde.<br />
Das Interessante an der Controller-Action, die diesen asynchronen Request verarbeitet, ist,<br />
dass sie im abschließenden Verarbeitungsschritt kein gewöhnliches ERb-, sondern ein<br />
sogenanntes RJS-Template ('Ruby JavaScript') rendert, welches ausschließlich Ruby-Code<br />
enthält:<br />
1 page[:nav_title].setStyle :margin => "0px 0px 0px 15px"<br />
2 page[:nav_title].setStyle :float => "left"<br />
3 page.select('.nav_option').each do |item|<br />
4 item.setStyle :float => "left";<br />
5 item.appear<br />
6 end<br />
Ohne den Code in Detail besprechen zu wollen, sei hier nur angemerkt, dass die Variable<br />
page zu Beginn von Zeile 1,2 und 3 ein JavascriptGenerator-Objekt referenziert.<br />
Beim Rendern dieses Templates wird mit Hilfe dieses Objekts, wie sein Name schon andeutet,<br />
Javascript-Code erzeugt, der an den Client geschickt wird. Die Antwort auf einen AJAX-<br />
Request besteht also nicht aus Daten (z.B. im XML-Format), die auf Client-Seite von einer<br />
JavaScript-Funktion verarbeitet werden, sondern aus JavaScript-Anweisungen, die direkt im<br />
Browser ausgeführt werden. So kann auf Server-Seite in Ruby codiert werden, welche DOM-<br />
Manipulationen als Ergebnis eines erfolgreichen Logins vorzunehmen sind 76 (wie z.B. die<br />
Anzeige von Navigationsmöglichkeiten, die für den nicht-eingeloggten User nicht sichtbar<br />
sind).<br />
7.4 Evaluierung von <strong>UWE</strong>: Umsetzbarkeit der Modelle<br />
Nachdem im letzten Unterkapitel die Vorgehensweise bei der Umsetzung der <strong>UWE</strong>-Modelle<br />
skizziert wurde, ist es an der Zeit, die Evaluierung von <strong>UWE</strong> mit einer Bewertung der<br />
Umsetzbarkeit der Modelle abzuschließen, die beim Entwurf des PVS entstanden sind. Dabei<br />
werden wir uns im Wesentlichen auf die Resultate beziehen, die in den Sektionen über die<br />
Umsetzung der einzelnen <strong>UWE</strong>-Teilmodelle vorgestellt wurden. Insofern ist dieser Abschnitt<br />
im Wesentlichen eine Zusammenfassung verschiedener Beobachtungen, die sich über das<br />
letzte Kapitel verteilt finden. Zunächst wollen wir jedoch einige Anmerkungen zur<br />
Aussagekraft und dem Umfang der folgenden Bewertung machen.<br />
Erstens: Auf eine gewisse Abhängigkeit des Kriteriums der Umsetzbarkeit mit dem der<br />
Verständlichkeit der Modelle wurde bereits in Kapitel 4.7 hingewiesen. Deswegen ist auch<br />
jetzt das Caveat angebracht, das schon bzgl. der Bewertung der Verständlichkeit<br />
ausgesprochen wurde: Wenn, wie in unserem Fall, der Modellierer selbst seine Modelle<br />
implementiert, so geht die Umsetzung natürlich leichter von der Hand, als wenn diese beiden<br />
Aufgaben auf verschiedene Personen aufgeteilt werden. Schwierigkeiten, die im letzteren Fall<br />
76 [30], S.73f<br />
91