Seite 3: ROCA: JavaScript

Inhaltsverzeichnis

ROCA-Basistechnik 3: JavaScript

Trotz der Forderung, dass der Server die Anwendungslogik verantwortet, ist es aus Gründen der Ergonomie sowie zur Reduzierung der Reaktionszeiten wünschenswert, möglichst viele Aufgaben bereits auf Clientseite zu verarbeiten. Dabei sollte jedoch Duplizierung der Anwendungslogik auf Clientseite, also die Reimplementierung bestimmter Kernteile in JavaScript, unbedingt vermieden werden. So bedeutet derartige Duplizierung zum einen potenziell höheren Wartungsaufwand. Zum anderen birgt das aber auch die Gefahr, dass die verschiedenen Implementierungen derselben Fachlichkeit sich unterschiedlich verhalten. Neben
den offensichtlichen Problemen der doppelten Implementierung, womöglich in der Verantwortung verschiedener Personen oder gar Teams, kann das einfache technische Gründe haben, etwa unterschiedliche Interpretationen von Zahlenwerten oder regulären Ausdrücken in der Server-Programmiersprache und in JavaScript.

Der in ROCA geforderte Verzicht auf doppelte Implementierung von Applikationslogik im Client bedeutet jedoch keinesfalls, dass ROCA-konforme Anwendungen Ergonomie und Nutzerfreundlichkeit opfern. Ziel ist vielmehr, die JavaScript-Logik so zu gestalten, dass der Server durch entsprechende Annotationen im ausgelieferten HTML die notwendigen Aspekte deklarativ an den Client übertragen kann. Dadurch entstehen auch hier generische Komponenten, die in der Regel keine direkte Fachlichkeit implementieren, sondern jeweils nur eine bestimmte Frontend-Logik.

Will man beispielsweise mit AJAX Informationen dynamisch nachladen oder aktualisieren, bedient man sich hierbei direkt der vom Server bereitgestellten Links sowie der dahinter liegenden HTML-Ressourcen. Dafür wird beispielsweise mit der JavaScript-Kompontente pjax das vorliegende HTML nach entsprechenden Links durchsucht, diese per AJAX vom Server geladen und das Resultat (bzw. Teile daraus) direkt in die Seite eingesetzt. Auf ähnliche Weise lassen sich Formularinteraktionen abfangen und die entsprechenden Teilinhalte dynamisch ersetzen.

Zwar ist es derzeit populärerer, den AJAX-Datenaustausch auf JSON-Strukturen zu beschränken und diese auf Clientseite in das gewünschte HTML zu transformieren, jedoch handelt es sich hierbei meist um Duplizierung bestehender Logik, da eine serverseitige HTML-Struktur oft auf Clientseite nachgebaut wird. Zudem hat sich etwa am Beispiel von Twitter gezeigt, dass diese Art des Seitenaufbaus in der Regel keinen bedeutenden Geschwindigkeitsvorteil bringt.

Auch Validierungen lassen sich mit generischen Komponenten auf Clientseite vornehmen, ohne dass konkrete Fachlogik doppelt zu implementieren ist: Der Server annotiert die entsprechenden Eingabeelemente dafür mit entsprechenden Validierungsmustern – etwa, ob das jeweilige Feld zwingend notwendig ist oder welches Format die Eingaben annehmen sollen. Eine clientseitige Komponente kann diese generisch verarbeiten und somit die Validierung ohne Serverinteraktion durchführen. Im Falle komplexer algorithmischer Validierungen funktioniert das natürlich nicht mehr. Hier kann man ebenfalls auf AJAX setzen und sich einer Komponente bedienen, die die aktuellen Formulareingaben periodisch vom Server im Hintergrund validieren lässt und die fehlerhaften Eingaben dann entsprechend hervorhebt.

Der Ansatz, bestimmte Frontend-Logik in einzelne JavaScript-Komponenten zu kapseln, entspricht generell sehr gut dem Prinzip des Progressive Enhancement: Die Logik beziehungsweise die entsprechende Komponente wird nur geladen oder angewandt, wenn der Browser die Grundlagen dafür unterstützt. Wenn nicht, lässt sich die Anwendung trotzdem weiter verwenden, da die eigentliche Fachlichkeit serverseitig komplett abgedeckt wird (zumindest, wenn man dem ROCA-Ansatz folgt). Außerdem werden andere Komponenten, deren Anforderungen vom Browser erfüllt werden, trotzdem geladen. Dieses Vorgehen wird auch oft als "Unobtrusive JavaScript" bezeichnet, wonach die essenziellen Aspekte der Website auch ohne JavaScript-Unterstützung funktionieren sollen.