Frameworks zum Erstellen von Webanwendungen gibt es viele, doch hat in letzter Zeit kaum ein Framework so viel Aufmerksamkeit auf sich gezogen wie das auf der objekt-orientierten Scriptsprache Ruby basierende Ruby on Rails. Diesen Umstand verdankt Ruby on Rails vor allem der Tatsache, dass es atemberaubend kurze Entwicklungszeiten verspricht, ohne dass man sich diese durch Nachteile wie eine langsame Ausführungszeit erkaufen müsste. Wir haben das Framework genau unter die Lupe genommen und uns die Frage gestellt, ob Ruby on Rails die Entwicklung von Webapplikationen revolutionieren kann.
Rails ist aus der Entwicklung einer Webanwendung, genauer gesagt der Kollaborations-Applikation Basecamp, entstanden. Das Framework wurde also nicht im Vakuum entwickelt, sondern aus einer laufenden Anwendung heraus extrahiert. Auch neue Features finden in der Regel über diesen Prozess Eingang in Rails. Damit entstehen nicht einfach Funktionen, weil es nett wäre, sie zu haben, sondern weil sie ein Bedürfnis in der Entwicklung abdecken.
Das Framework besteht aus verschiedenen Klassen (siehe Kasten «Architektur von Ruby on Rails»), die alle Aspekte der Entwicklung von Webanwendungen abdecken. Es verwendet das in Smalltalk erstmals angewandte MVC-Schema (Model View Controller). Dieses trennt scharf zwischen Geschäftslogik und Datenmodell (Model), der Sicht des Benutzers (View) sowie der Möglichkeiten des Benutzers, das Model zu beeinflussen (Controller).
Verschiedene Prinzipien liegen dabei der Entwicklung des Frameworks zugrunde: DRY ist sicher eines der wichtigsten. DRY steht für «Don't repeat yourself», was soviel heisst, dass eine Tatsache nur ein einziges Mal beschrieben wird. Hier ein Beispiel: Ein Datenmodell ist implizit durch das Datenbankschema beschrieben. Um damit zu arbeiten, müsste man in anderen Frameworks eine formale Repräsentation davon haben (z.B. in XML). Rails wertet dagegen direkt die Datenbank aus – Änderungen in der Datenbank schlagen sich direkt im Objektmodell nieder. Der Zwischenschritt – und damit eine mögliche Quelle für Fehler – wird vermieden.
Ein weiteres Prinzip ist «Weniger ist mehr». Die erste Fassung von Rails umfasste gerade einmal 1000 Zeilen Code, die aktuelle ist mit rund 4000 Zeilen nicht sehr viel grösser. Dies rührt sicher auch daher, dass David Heinemeier Hansson, der Vater von Rails, sehr strenge Kriterien ansetzt, wenn es darum geht, was in Rails aufgenommen wird und was nicht. Ein einfaches «wäre es nicht nett, wenn...» reicht dabei nicht. Erweiterungen entstehen nicht aus theoretischen Überlegungen, sondern werden aus realen Anwendungen extrahiert, wenn sie sich dort bewährt haben. Erweiterungen sind trotzdem jederzeit möglich: Da Rails komplett in Ruby geschrieben ist, steht es jedem Entwickler frei, es sich nach seinen Bedürfnissen anzupassen.
«Weniger ist mehr» heisst aber auch, dass der Entwickler weniger zu tun hat. Die Beschreibung von Validierungskriterien in einem Datenmodell führt automatisch dazu, dass Rails Eingaben auf Plausibilität prüft und den Benutzer mit aussagekräftigen Fehlermeldungen auf die richtige Spur führt. Die Beschreibung von Abhängigkeiten in der Form «has_one», «belongs_to» oder «has_and_belongs_to_many» definiert, in welcher Beziehung Objekte zueinander stehen und gibt Rails genug Informationen, um sämtliche nötigen SQL-Statements automatisch zu generieren. Der Kasten «Zettelwirtschaft» zeigt beispielhaft, wie wenig es neben den Datenbanktabellen braucht, um das Datenmodell einer Anwendung zu erstellen. Durch die verschiedenen «validates...»-Statements werden bereits die Regeln für die spätere Validierung von Benutzereingaben vorgenommen. Ohne zusätzlichen Aufwand werden alle Objekte während des Speicherns überprüft, ob sie den Bedingungen entsprechen. Im Falle eines Fehlers verweigert Rails die Arbeit und zeigt dem Benutzer die sprechende Fehlermeldung an.
Da Rails für die Entwicklung von Webanwendungen konzipiert wurde, kümmert sich das Framework auch um die HTML-Seiten. Sie werden dynamisch aus Schablonen erzeugt, die in einer Mischung aus HTML und Ruby geschrieben sind. Damit geht Rails einen anderen Weg als die Java-Welt, in der es gang und gäbe ist, eine weitere Script- oder Template-Sprache zur Steuerung der HTML-Seiten zu verwenden.
Neben den HTML-Darstellungen ist es auf gleiche Art möglich, XML-Ansichten auf die Daten zu erzeugen. Auch hier verwendet man Schablonen, die ebenfalls den gesamten Umfang von Ruby ausnutzen.
Besonders für Projekte in grösseren Teams wirkt sich vorteilhaft aus, dass Rails-Anwendungen immer gleich strukturiert sind. Dadurch finden sich die verschiedenen Dateien immer an derselben Stelle wieder. Zudem generiert Rails automatisch für Modelle und Controller Unit- und funktionale Tests komplett mit Beispieldaten. Es unterstützt damit die Praktiken des «Test Driven Development». Da auf diese Weise sämtliche Routine-Arbeiten durch das Framework übernommen werden, kann man sich als Programmierer um die wesentlichen Dinge wie Logik und Präsentation kümmern. Und weil die Tests ein natürlicher Bestandteil eines Projektes sind, führen sie zu stabileren Anwendungen.
Es soll aber nicht verschwiegen werden, dass auch dieser Ansatz nicht immer funktioniert. Damit Rails seine Vorteile ausspielen kann, müssen etwa die Tabellen der verwendeten Datenbanken gewisse Voraussetzungen bei der Namensgebung erfüllen. So erwartet Rails etwa, dass es eine Spalte mit dem Namen «id» gibt oder dass der Tabellenname der Plural des verwendeten Objektes ist (Objekt: Note, Tabelle: notes). Für Anwendungen, die auf der grünen Wiese entstehen, ist das kein Problem. Muss man aber bestehende Datenbanken integrieren, kann die Anpassung an die Rails-Konventionen durchaus in Arbeit ausarten oder sogar den Einsatz von Rails unmöglich machen. Hier leistet ein Framework wie Hibernate mehr – es hilft aber nur gerade bei der Brücke zwischen Datenbank und Objekten. Darstellung oder Steuerung müssen anderweitig gelöst werden, was zudem für eine höhere Komplexität sorgt.
Zu Beginn eines Projektes, kann man sich seine Anwendung mit «Scaffolding» (Baugerüst) erstellen lassen. Rails erzeugt dann generische HTML-Formulare und Controller, mit denen sich die Anwendung bedienen lässt. Aufbauend auf diesem Gerüst kann man dann Stück für Stück ein eigenes Aussehen und eigene Funktionalität ergänzen. Auf diese Weise erhält man innert weniger Minuten eine funktionierende Anwendung mit CRUD-Funktionalität (Create/Read/Update/Delete). Jede Änderung am Code, am Layout oder an der Datenbank ist nach neuem Laden des Browser-Fensters sichtbar. Das Wegfallen von jeglichen Konfigurationsscripts, Kompilierungsschritten und Deployment-Prozessen führt zu einem rasend schnellen, beinahe interaktiven Entwickeln.
Dass es Ruby on Rails nicht nur gelingt, bei der Anwendungsentwicklung, sondern auch beim produktiven Einsatz zu überzeugen, zeigen bereits eine Reihe von Applikationen und Diensten. So sind mit Basecamp (www.basecamphq.com) oder 43Things.com (www.43things.com
) gleich mehrere komplett mit Ruby on Rails entwickelte Services online, die erfolgreich eine grosse Benutzerbasis bedienen. Und auch wenn noch unabhängig bestätigte Tests fehlen, zeigen bereits diese Anwendungen, die viele tausend Benutzer mit moderaten Hardware-Anforderungen bedienen, dass das Framework durchaus skalieren kann. Dass es dabei noch nicht mal die Version 1.0 erreicht hat, tut der kontinuierlichen Entwicklung weiterer Applikationen keinen Abbruch.
Ajax ist in diesem Fall kein Spülmittel, sondern steht für «Advanced Javascript and XHTMLHttpRequest», einer bereits einigen Jahre alten Technik, die endlich einen eingängigen Namen gefunden hat. Herausragendes Beispiel für den Einsatz von Ajax ist GMail von Google, einer Webmail-Anwendung, die sich dank dieser Technik nicht mehr wie eine Browser-basierte, sondern wie eine traditionelle GUI-Anwendung bedienen lässt.
Ajax basiert darauf, dass der Browser im Hintergrund mit dem Webserver kommuniziert, Daten austauscht und nur Bereiche der aktuellen Webseite neu zeichnen kann – all das vermeidet den «Hin-und-Her-Verkehr», der bei jeder Aktion zu einem kompletten Neuladen der Webseiten führt.
Jens-Christian Fischer
beschäftigt sich seit 15 Jahren mit dem Automatisieren von Geschäftsabläufen, dem Web
und Intranets im speziellen.
Er ist Geschäftsführer der InVisible GmbH, Zürich.
