User Interface mit Architektur

Mojo und jQuery Templates

Ein modernes CMS wie Mojo muss sich im User Interface, und damit in der Bedienung und Handhabung, mit dem Qualitätsanspruch von Desktop-Applikationen messen können. Diese Qualität kann nicht durch statische Inhalte erreicht werden sondern erfordert ein hohes Maß an flüssiger Interaktion. jQuery Templates fügt sich dafür wunderbar in unsere UI Architektur ein.

Die Geschwindigkeit mit der ein UI auf Eingaben reagieren muss, damit die Interaktion subjektiv als „flüssig“ wahrgenommen wird, liegt im Bereich einer Zehntelsekunde. Um diese response time in einer Internetapplikation wie Mojo erzielen zu können, muss ein Teil der Applikationslogik lokal innerhalb des Browsers ablaufen. Dadurch kann das UI von der über das Internet zu langsamen Datenverbindung mit dem Server entkoppelt werden: Und die für das Interaktionserlebnis relevanten Teile werden nicht mehr ausgebremst. Unsere so konzipierte Architektur ist in Abbildung 1 skizziert.

UML Verteilungsdiagramm Abbildung 1: UML Verteilungsdiagramm zur Architektur

Mojo im Browser

Der allgemeine Anwendungfall im Browser ist das Anzeigen und Manipulieren von Daten (Stories, Bilder etc.) in einer dafür vorgesehenen Maske, auch User Interface genannt. Um die Interaktion so flüssig wie möglich zu halten darf nun nicht jede Änderung im UI zu einem zwingendem Datenaustausch mit dem Server führen. Es soll z.B. die Maske, mit welcher der Storycode bearbeitet wird, sofort und ohne Rücksprache mit dem Server eingeblendet werden (siehe Abbildung 2).

Um das zu erreichen muss innerhalb des Browsers eine eigene Software Architektur mit zumindest folgenden Komponenten vorhanden sein :

  • Die relevanten Daten in manipulierbarer Form, z.B. Story-Objekte.
  • Templates um Elemente im UI hinzufügen zu können, z.B. ein Template um die Änderungsmaske einer Story anzuzeigen.
  • Viel JavaScript Code der die Anzeige des UI kontrolliert, auf Usereingaben reagiert und den Datenaustausch mit dem Server organisiert: Beispielsweise kümmert sich das JavaScript um die Anzeige einer Story innerhalb der Änderungsmaske oder registriert das Klicken des Users auf den „Speichern“-Knopf und leitet das Speichern an den Server weiter.

Im Prinzip folgen wir hier dem klassischen Model-View-Controller Entwurfsmuster: Es gibt die Story-Objekte (Model), die Templates (View) und den JavaScript Code (Controller). Den Controller entwickeln wir selbst und bedienen uns für Teile seiner Funktionalität an jQuery Plugins.

CMS Manager Tabelle mit eingeblendeter Maske zum Story bearbeiten Abbildung 2: Die Maske zum Bearbeiten des Storycodes

Eine passende Templating Engine

Ein wichtiger Teil des Controllers ist die Logik mit der neue Elemente für das User Interface erstellt und angezeigt werden: Die Templating Engine. Seit Version 1.5 gibt es eine jQuery eigene Templating Engine namens jQuery Templates. Diese wurde von Microsoft hausintern als jQuery Plugin entwickelt und Mitte 2010 an das OpenSource Projekt und damit an die Öffentlichkeit übergeben.

Wir arbeiten gerade daran unsere eigenes (selbst entwickeltes) Templating komplett auf jQuery Templates umzustellen, da wir uns davon Verbesserungen in mehreren Bereichen versprechen:

  • Die Templates werden bei Verwendung zu Scripts kompiliert und gecached. Das erhöht die Geschwindigkeit beim Rendern von neuen UI Elementen.
  • In den Templates können mit einer eigenen Template Sprache Daten vor der Darstellung manipuliert werden (Preprocessing).
  • Die Template Sprache ist simpel und in ihrer Syntax ähnlich wie JavaScript.
  • Das Plugin wird von einer aktiven Community weiterentwickelt, betreut und dokumentiert.
  • Es fügt sich gut in unser wachsenden jQuery Ökosystem ein.

Ein Blick in die Suchmaschine zeigt uns, dass es 1001 Templating Engines für JavaScript gibt. Es gilt die eine zu finden die sich optimal in die (bestehende) Architektur einfügt.

Bei der Umstellung gab es bisher noch keine unlösbaren Probleme - wir konnten auch komplexe Darstellungsroutinen in Form von jQuery Templates problemlos abbilden. Die Template Sprache ist aufgrund ihrer Nähe zu JavaScript einfach zu erlernen und zu verwenden. Die damit erstellten Templates sind aussagekräftig und leicht lesbar.

Dokumentation

Die Dokumentation von jQuery Templates ist derzeit gut wenn auch etwas verstreut. Ich möchte daher hier auf ein paar Informationen explizit verweisen: Die allgemeine Einführung von einem MS Entwickler, der Einstieg in die Sprachelemente der Templates und eine Übersicht aller Dokumente zu jQuery Templates.

Bei den Sprachelementen waren für uns speziell die Möglichkeiten an Preprocessing von Daten von Interesse, z.B. um ein Datum für unterschiedliche UI Elemente verschieden zu formatieren. Grob zusammengefasst kann man aus einem Template auf Funktionen zugreifen, die zu rendernden Daten mitgeben und das Ergebnis der Funktion anzeigen. Dieser Mechanismus ist im Absatz „Evaluating Expressions and Functions“ erklärt.

Fazit

Vor allem die User profitieren von einer Auslagerung UI spezifischen Codes auf den Browser: Für sie wird das Nutzungserlebnis nachhaltig positiv beeinflusst, die Webapplikation (egal ob CMS oder Webmail) reagiert „snappy“ und die Interaktion geht flüssig von der Hand. Um das technisch zu ermöglichen braucht es im Browser eine ebenso professionelle Architektur wie auf dem Server. Als Komponente für das Rendern von UI Elementen ist jQuery Templates auf jeden Fall einen Blick wert.

Marius Lessiak,