08.12.2012 Aufrufe

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

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

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

MEHR ANZEIGEN
WENIGER ANZEIGEN

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

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!