Ein Ausblick auf die kommende Version des schlanken Web-Frameworks: Ruby on Rails 2.0
Das Rails-Team ist zufrieden mit sich und seinem Framework, das bereits über eine Million Downloads und hunderte Plugins zählt. Entsprechend stand die Keynote von Heinemeier Hansson [1] unter dem Motto „Celebrating what we have“. Die gleiche Stimmung spiegelt auch das kommende Release 2.0 von Ruby on Rails wieder: Anstatt auf künstliche Innovationen, setzt die neue Version auf viele kleine Detailverbesserungen.
REST statt SOAP
Web Services werden in der Zukunft standardmäßig über die RESTful implementierten „Active Resources“ realisiert. Folglich wird das REST-Konzept auch in Rails immer zentraler. Wer aber weiterhin auf „SOAP“ setzen möchte, kann dies auch weiterhin tun.
Breakpoints
In Version 1 wurde der „Breakpointer“ häufig zum Debugging verwendet. So lange, bis ein Ruby-Bugfix den „Breakpointer“ unbrauchbar machte. In Version 2 können wieder Breakpoints gesetzt werden, allerdings mit dem Keyword „debugger“ (früher: „breakpoint“). Neu ist neben dem Namen auch eine erweiterte Funktionalität: Wie bisher landet man beim Erreichen des Breakpoints in einer IRb-Session, kann dort aber jetzt auch den Stack durchwandern.
HTTP Performance
Werden viele einzelne JavaScript- und CSS-Dateien auf einer Seite eingebunden, erhöht sich die Wartezeit für den Besucher, bis die Seite angezeigt werden kann. Der Grund dafür: Browser können nur wenige (normalerweise zwei) simultane Requests vom gleichen Host zulassen. Rails 2.0 löst das Problem, indem es die Dateien zusammenführt und komprimiert. Folgende zwei Zeilen machen aus den projektabhängig oftmals unzähligen CSS- und JavaScript-Dateien jeweils eine einzelne Datei:
<%= javascript_include_tag :all, :cache => true %> <%= stylesheet_link_tag :all, :cache => true %>
Listing 1
Um die HTTP-Performance zu verbessern, lassen sich in Rails 2.0 auch spezielle Asset-Server konfigurieren, um beispielsweise mehr simultane Downloads zuzulassen:
config.action_controller.asset_host = “assets%d.example.com“
Listing 2
Query Cache
Ein neu eingeführter Cache auf der Applikations-Ebene sorgt dafür, dass keine unnötigen Datenbank-Abfragen entstehen, die Zeit und Performance kosten. Dadurch können einmal abgefragte Daten direkt verwendet werden – ohne den Umweg über die Datenbank. Sehr angenehm am Query Cache ist, dass er von selbst geleert wird, wenn eine betreffende Änderung an den Daten (insert/delete/update) vorgenommen wird.
Namenskonventionen
Eine Zweiteilung der Dateinamen-Erweiterung für Template-Dateien soll in Rails 2.0 eine verbesserte Auskunft darüber geben, welche Engine welches Format ausgibt. Der erste Teil nennt das Ausgabeformat, der zweite Teil die zuständige Engine:
- index.html.erb
- index.xml.builder
- index.rss.erb
- index.atom.builder
Flexiblere Umgebungskonfiguration
Die Dateien zur Umgebungskonfiguration können bei größeren Projekten schnell komplex und unübersichtlich werden. Rails 2.0 erlaubt es, die Konfigurationen besser auf einzelne Dateien aufzuteilen. Das vereinfacht auch die Wiederverwendung.
Neue Migrationen
Gerade Tabellen mit vielen Feldern waren in den Migrationen oft mit viel dupliziertem Code verbunden. Felder gleichen Typs mussten, obwohl sie absolut gleich konfiguriert waren, ebenso umfangreich wie ihre Vorgänger definiert werden. In den neuen Migrationen in Rails 2.0 tauschen nun Feld-Typ und Feld-Name die Plätze. Hier ein Vergleich zwischen alt und neu:
HTTP-Authentifizierung
Auf den ersten Blick mag es verwundern, dass Rails 2.0 die gute alte HTTP-Authentifizierung stärker einbindet – für die meisten Anwendungsfälle ist der Klassiker schließlich nicht gerade „State of the art“. Doch für Datendienste, zum Beispiel für Feedreader, ist diese Authentifizierung durchaus sinnvoll. Rails 2.0 kann Clients, die XML-Daten anfordern, den Zugriff sehr leicht über die HTTP-Authentifizierung erlauben, während andere Formate nach gewohnter applikationsspezifischer Authentifizierung ausgegeben werden.
Um Lizenzfragen bei Plugins zu vereinfachen, erstellt der Generator für ein neues Plugin gleich eine Datei mit der MIT-Lizenz. Soll für das selbst erstellte Plugin eine andere Lizenz gelten, kann die MIT-Lizenz an die eigenen Bedürfnisse angepasst werden.
Wie in jeder Version werden einige Features als „deprecated“ (wörtlich „missbilligt“) gebrandmarkt und einige uralte Features endlich komplett entfernt. Über diese Routine-Tätigkeiten hinaus werden auch einige Features (z. B. die InPlaceEditing-Makros) aus der Kern-Applikation ausgelagert und in eigene Plugins verpackt.
Fazit
Rails wird auch in der Version 2.0 keine „eierlegende Wollmilchsau“ sein. Statt den Anspruch zu erheben, ein universaler Problemlöser zu sein, bleibt Rails mit Version 2.0
seiner Linie treu: schlank und fokussiert – auch das brachte Rails-Kopf Heinemeier Hansson während der RailsConf deutlich zum Ausdruck.