A Programmer's Blog

JS-Labs PT.3: Schlankere Controller durch Bindings mit AngularJS!

Apr
26

In meinem letzten Post habe ich gezeigt wie Jasmine und Coffeescript schönen Test-Code schreiben kann. In diesem Post werde ich zeigen wie sich Controller-Code durch Bindings mit AngularJS vereinfachen lässt.

Mein bisheriger Controller

Meine Arbeiten an der jQuery-Version des Wakmarks-Projekts neigen sich dem Ende zu. Ein Anti-Pattern was sich herauskristallisiert ist, dass der Controller bei diversen Events sowohl Model als auch View aktualisieren muss.

Als Beispiel soll hier der ‘click’-Handler auf dem “gelesen”-Button eines Bookmarks dienen. Mit dem Button lässt sich der Zustand eines Bookmarks zwischen “gelesen” und “ungelesen” wechseln:

onBookmarkReadClick : (event) ->
 bookmarkView = $(event.target).parents(".bookmark")
 # update the model ...
 bookmark = Bookmark.find(bookmarkView.data('id'))
 bookmark.read = !bookmark.read
 # ... and the view :(
 if(bookmark.read)
   $(event.target).addClass('read')
   $(event.target).removeClass('unread')
 else
   $(event.target).addClass('unread')
   $(event.target).removeClass('read')

Das “M” und das “V” im MVC

Schön wäre es, wenn der Controller nur das Model aktualisieren müsste und sich der View dann automatisch aktuallisiert. Im klassischen MVC wird das Problem durch das Observer-Muster gelöst.

(original von Wikipedia)

In meinem Beispiel besteht der View aber aus purem HTML:

<div data-id="1">
 ...
   <button class="unread">&nbsp;</button>
 ...
</div>

Was also tun?

Bindings

Glücklicherweise gibt es Frameworks die sogenannte Bindings anbieten. Durch Bindings lassen sich Attribute des Models an HTML-Elemente des Views binden und automatisch damit synchronisieren. Letztendlich handelt es sich um vereinfachte Variante um mit dem Observer-Musters zu arbeiten.

Mit AngularJS kann der Code des Controllers damit stark vereinfacht werden:

$scope.onBookmarkReadClick = (bookmark) ->
  bookmark.read = !bookmark.read
$scope.getBookmarkReadClass = (bookmark) ->
  if bookmark.read
    "read"
  else
    "unread"

Eigentlich wäre es ein Zweizeiler gewesen, aber leider leider unterstützten AngularJS-Bindings keine Kontrollstrukturen, weshalb es die weitere Methode “getBookmarkReadClass” benötigt um den read-Flag in einen CSS-Klassennamen umzuwandeln.

Der View sieht dann so aus:

<div class="bookmark" data-id="{{bookmark.id}}">
 ...
   <button class="{{getReadClassName(bookmark)}}">&nbsp;</button>
 ...
</div>

Filter

Mir gefällt diese Variante schon deutlich besser, aber mich stört die Methode “getBookmarkReadClass” in meinem Controller. Es gibt in AngularJS auch die Möglichkeit eigene Filter zu definieren, damit liesse sich der View in etwa so schreiben:

<div data-id="{{bookmark.id}}">
 ...
   <button class="bookmark.read | to_bookmark_class">&nbsp;</button>
 ...
</div>

Die Methode “getBookmarkReadClass” könnte damit entfernt werden. Allerdings habe ich es nicht geschafft einen solchen Filter zu schreiben, da die Dokumenation nicht aktuell ist.

Weitere Frameworks mit Binding-Support

Morgen werde ich mir noch Batman-JS anschauen. Ein weiteres Framework mit Bindings wäre noch Ember-JS, welches aber leider nicht zu CoffeeScript kompatibel ist. Ein Vergleich verschiedener MVC Frameworks gibt es hier.

 

JS-Labs – Wakmarks PT.1

Apr
22

In den nächsten Tagen werde ich verschiedene Frameworks zur RIA-Entwicklung austesten. Primär interessieren mich dabei die folgenden Punkte:

  • MVC
  • Dependency Injection
  • Testbarkeit
  • Performance

Momentan habe ich vor allem einen Blick auf AngularJS und JavascriptMVC.

Ich habe mir zu Testzwecken eine kleine WebApp überlegt um Bookmarks zu verwalten. Natürlich gibt es dafür schon tausende, es geht jar nur ums ausprobieren 😉

Ich werde in nächster Zeit drei Protoypen bauen, jeweils mit UnterschiedlichenTTechnologien:

  1. jQuery plus diverse Plugins für Unit-Tests und Klassen.
  2. AngularJS
  3. JavascriptMVC

Die statische Variante (ohne Funktion) ist bereits hier (ja ich weiss: schön ist was anderes ;D). In den folgenden Parts werde ich dann die einzelnen Prototypen vorstellen.

Rest in peace Flex … oder: was ich in der Javascript-Welt vermisse …

Apr
21

Seit ich HTML und Javascript entwickele, wächst in mir eine Trauer. Ich trauere um Flex und ich trauere um Actionscript. Ich trauere um eine Art der RIA-Entwicklung, wie sie sein sollte. Actionscript und vor allem das Flex-Framework boten so vieles, was ich in der Javascript-Welt einfach nicht wiederfinde.

Im Folgenden werde ich auf einige Dinge eingehen, die mir ganz besonders fehlen. Für Lösungsvorschläge bin ich natürlich sehr dankbar!

Vollständige, flexible und stylebare UI-Komponenten

Hier hatte ich nie mit Problemen gerechnet. Für mich war beim Wechsel ganz klar, das es da draussen UI-Bibliotheken geben müsse, die zumindest annähernd so vollständig und flexibel sind, wie die von Flex … Aber Pustekuchen!

jQueryUI, YUI und wie sie alle heissen, sie alle bieten nur eine unvollständige Anzahl an zusammengewürfelten Komponenten, die wenig mit einemv ollständigen Baukasten für eine RIA zu tun haben. Zudem haben sie meist kein einheitliches Konzept von Erweiterbarkeit oder Wiederverwendbarkeit. Und noch dazu ist das Styling in CSS meist die Hölle. Mein Lieblingsbeispiel ist hier das Menu von YUI-3 : Schwierig zu stylen, so gut wie nicht konfigurierbar, es gibt überhaupt keine Events und beim Initialisieren der Seite zickt und zuckt es das ich Augenkrebs bekomme. Und das ist die Zukunft?

Wer mir ein open-source UI-Framework nennen kann, das so vollständig, so einfach zu verwenden, zu stylen und trotzdem so anpassbar wie Flex ist, dem werd ich persönlich die Füße küssen!

Data-Binding

In Flex ist das Entwickeln von Views einfach genial. Mittels Data-Binding werden Daten des Models gebunden und damit ist das View-Verhalten ganz klar vom Controller-Code getrennt. Und wie ist das mit jQuery? Hmm … zugegeben: es ist deutlich besser als mit reinem Javascript, aber jetzt manipuliert man mit jQuery Daten des DOM und wo liegt dieser Code? Im Controller? Gehört er hier wirklich hin? Ein Blick in die Dokumentation von JavascriptMVC bestätigt es mir, ja da kommt er hin!

Durch Data-Binding in Flex ist es möglich Views zu entwickeln, von denen der Controller nichts weiss. Ich denke dies ist der richtige Weg um Wiederverwendbarkeit zu erlangen, da der View jederzeit ausgetauscht werden kann, genauso wie der Controller. Mit gängigen Javascript-Frameworks wird das ganze so streng mit einander verwoben, das hier von Wiederverwendbarkeit keine Rede sein kann.

ECMAScript 4

ECMAScript 4 … das sollte einmal ein Javascript-Standard werden:

Though flexible and formally powerful, the abstraction facilities of ES3 are often inadequate in practice for the development of large software systems. ECMAScript programs are becoming larger and more complex with the adoption of Ajax programming on the web and the extensive use of ECMAScript as an extension and scripting language in applications. The development of large programs can benefit substantially from facilities like static type checking, name hiding, early binding and other optimization hooks, and direct support for object-oriented programming, all of which are absent from ES3.

ECMAScript 4 wurde aber aus irgendwelchen politischen Gründen der Browserhersteller verworfen, allerdings erst nachdem Actionscript 3 diesen Standard bereits adaptiert hat. Mir ist es bis heute nicht klar warum, dieser Standard hätte so vieles ändern können. Während Actionscript sich bereits seit guten 5 Jahren wie eine ausgewachsene Programmiersprache anfühlt, fühlt man sich bei Javascript immer noch wie ein Script-Kiddie, dem offenbar keine Grenzen gesetzt sind.

Bei Javascript ist alles möglich und das liegt hauptsächlich am sog. “Prototyping“, dem Vererbungsmechanismus in Javascript. Das Prototyping ist meiner Meinung nach eine Katastrophe, die Dinge zulässt, die in einer objektorientierten Programmiersprache nicht möglich sein dürfen. Und was haben wir statt dem? Dutzende Frameworks, die versuchen genau diese Probleme lösen, in dem mittels Prototyping eine Abstraktion geschaffen wird, um eine OO-Sprache nachzuahmen. Jedes Framework meint das besser zu können als andere Frameworks. Damit ist jede einzelne Klasse, die ich in einem solchen Framework schreibe, eben an dieses Framework gebunden. Mit anderen Worten: Fast jedes Framework bringt seine eigene Programmiersprache mit sich.

Multimedia-Formate

Dazu gibt es nicht viel zu sagen: in Flash brauche ich ein Video oder Musikstück nur in einem Format ausliefern, in der HTML-Welt muss ich Multimedia-Formate für verschiedene Browser in verschiedenen Formaten abliefern. Hier wird so schnell leider keine Javascript Bibliothek Abhilfe schaffen können.

Event-Modell

Das Event-Modell von Javascript ist nicht einheitlich. Der eine Browser unterstützt Event-Bubbling, der andere Event-Capturing und mit jQuery erhalte ich auch ein einheitliches Event-Modell, bei dem ich aber folglich weder Bubbling noch Capturing verwenden darf, weil eben nicht jeder Browser unterstützt wird. Korrigiert mich bitte wenn ich hier falsch liege. Auch hier wird leider kein Framework Abhilfe schaffen können.

Fazit

Wie gut die Aussicht hinsichtlich UI-Komponenten ist, weiss ich nicht. Ich hoffe einfach darauf, dass irgendwann einmal das Thema von kompetenten Entwicklern in die Hand genommen wird und ein reichhaltiges UI-Framework geschaffen wird. Leider ist dies keine einfache Aufgabe, hier sind sicherlich viele Mannjahre an Arbeit erforderlich.

Hinsichtlich Data-Binding ist das AngularJS-Framework sehr vielversprechend. Dieses werde ich mir in nächster Zeit genauer anschauen.

Die Punkte ECMAScript 4, Multimedia-Formate und Event-Modell sind mit einer Javascript Bibliothek oder einem Framework vermutlich nicht so einfach lösbar. Das ist die alleinige Schuld der Browser-Hersteller!

Ich sehne mich nach einer Zukunft ohne Flash, aber in dieser Zukunft muss die HTML-Welt liefern, was in Flash schon seit Jahren Realität ist!