"Ruby on Rails" umfangreich renoviert

Nach zwei Release Candidates ist jetzt die offizielle Version 2.3 des quelloffenen Web-Frameworks Ruby on Rails erschienen. Hatte Rails-Erfinder David Heinemeier Hansson 2007 noch davon gesprochen, dass es nur noch evolutionäre Veränderungen in Rails geben werde, war schon Rails 2.2 mit der Einführung von i18n API, Multithreading und experimentellem Ruby-1.9-Support wieder ein eher umfangreiches Release.

Mit Version 2.3 erfährt das Framework noch weit mehr Änderungen. Eine der wichtigsten sitzt unter der Haube: Die in die Jahre gekommenen CGI-Bibliothek im Kern von Rails wird durch Rack ersetzt. Rack ist eine einfach gehaltene Schnittstelle für die Anbindung von Webanwendungen an Webserver. Es übernimmt dabei die Ideen des Web Server Gateway Interface der Programmiersprache Python.

Für die Verwendung von Rack spricht zum einen, dass Anbindungen für so ziemlich jeden Web- oder Applikationsserver in der Ruby-Welt (inklusive des Apache-Moduls mod_passenger) bereits existieren, die Entwickler dieser Server für Rails also keine eigenen Lösungen entwickeln müssen. Zum anderen entsteht um Rack herum gerade ein interessantes Ökosystem anderer Web-Frameworks und sogenannter Middleware-Lösungen, die Aufgaben wie Caching und Kompression übernehmen können.

Rack bietet darüber hinaus die Möglichkeit, über einfache Konfigurationen verschiedene Webanwendungen und Middleware gleichzeitig verwenden und zum Beispiel je nach URL auf das eine oder andere Web-Framework zugreifen zu können. Durch die konsequente Umstellung der Rails-Interna auf Rack-Mechanismen sind nun auch Session-Daten zwischen diesen Frameworks auszutauschen.

Auch andere Teile von Rails haben die Entwickler überarbeitet: Nachdem die Funktion ursprünglich für Rails 2.2 angekündigt war, hat ActiveRecord endlich die verschachtelten Modell-Zuweisungen erhalten, über die Daten für verknüpfte Objekte mit einer einfachen Syntax direkt zugewiesen und entsprechende Objekte erzeugt werden können. Ebenfalls kann man nun mehrere Datenbank-Transaktionen verschachteln, was bei vielen Entwicklern schon lange auf der Wunschliste stand.

Weitere Änderungen gibt es bei den mit Rails 2.1 eingeführten Named-Scopes, die sich jetzt auch dynamisch erzeugen lassen. Zusätzlich kann man für ein Modell einen Default-Scope festlegen, mit dem man Aufgaben wie eine vorgegebene Sortierung oder aber auch das virtuelle Löschen von Objekten lösen kann. Als letzte erwähnenswerte Änderung bei ActiveRecord kann man in unterteilten Paketen über Objekte iterieren, was das effiziente Batch-Processing von großen Tabellen effizienter gestalten kann.

Im Controller- und View-Bereich gibt es ein paar Veränderungen an der i18n API: So kann man beispielsweise jetzt lokalisierte Views anlegen, die den Namen der Locale im Dateinamen enthalten, was für besonders textlastige Views hilfreich ist. Als eine der größeren Veränderungen hat sich die Syntax für render deutlich vereinfacht, sodass man sowohl für das Rendern von Templates als auch von Partials oft nur noch das Nötigste an Parametern übergeben muss. Die HTTP- ist durch eine Digest-Authentifizierung ergänzt worden.

Das Routing ist in Rails 2.3 deutlich effizienter geworden, dem sind allerdings die formatted_-Routes, die für REST-Routes automatisch erzeugt wurden, zum Opfer gefallen, sodass sich die Syntax für das Erzeugen von Links zu Ressourcen mit anderen Content-Types leicht geändert hat. Außerdem werden in Rails 2.3 erstmals offiziell die sogenannten Engines unterstützt, was in sich gekapselte Rails-Anwendungen sind, die man dann in eine Rails-Anwendung integrieren kann.

Im Bereich ActiveSupport ist insbesondere die Einführung von Object.try zu nennen, mit dessen Hilfe man, wie der Name sagt, "versuchen" kann, auf einem Objekt eine Methode aufzurufen. Existiert diese Methode nicht (zum Beispiel weil das Objekt den falschen Typ hat, da es nil ist), wird nil zurückgegeben anstatt eine Exception zu werfen. Dies kann zum Beispiel Views fehlertoleranter gestalten.

Ebenfalls neu ist die Unterstützung von sogenannten Application Templates, mit deren Hilfe man ein Grundgerüst für eine Anwendung definieren kann, das automatisch beim Anlegen der Anwendung zu erzeugen ist. Das kann die Installation von Plug-ins, das Deklarieren von gem-Dependencies, der Aufruf von Generatoren, aber auch das Ausführen von Shell-Kommandos bedeuten. Auch kann man dadurch die Setup-Zeit für neue Anwendungen verkürzen. Auf Github findet sich bereits eine ganze Reihe von Templates für unterschiedliche Zwecke, und mit Railsboost gibt es einen Generator für diese Templates, bei dem man sich die Konfiguration mit ein paar Klicks zusammenstellen kann.

Schon in dieser Version ist der Einfluss des Merb-Teams auf die Rails-Entwicklung deutlich spürbar – Ende Dezember hatten die beiden Projekte ihre Fusion angekündigt. Man darf gespannt sein, wie viele der Ideen von Merb Eingang in Rails 3 finden und ob das Rails-Team es schafft, die damit vermutlich einhergehende Modularisierung für den typischen Rails-Entwickler weitgehend transparent zu halten. (Jan Krutisch) / (ane)