Eines der großen neuen Features in Rails 3.1 ist die so genannte Asset Pipeline. Hiermit ist es möglich, die JavaScript und CSS Assets des Projektes zu komprimieren und zu minimieren. Des weiteren lassen sich mehrere Assets zu einer Datei zusammenführen. Ich möchte euch hier die Features der Asset Pipeline und diesbezüglich die Neuerungen in Rails 3.1 erläutern.
Die Asset Pipline ist eines der großen, neuen Hauptfeatures in Rails 3.1, welche aber auch einiges an Verwirrung stiften kann. Wenn du mit der Asset Pipeline noch komplett unvertraut bist, lies vorher den Rails Guide zur Asset Pipeline. Dieser deckt einen großen Teil der Features ab.
Solltest du bereits eine Rails 3.1 Applikation erstellt haben, findest du unter /assets/application.js JavaScript Code für deine Applikation. Aber wie funktioniert das?
Jede Datei, welche unter /app/assets/javascripts abgelegt wird, ist über /assets/* aufrufbar. Wenn wir in dem Ordner z.B. die Datei greetings.txt erstellen, ist diese unter http://localhost:3000/assets/greetings.txt erreichbar. Auch wenn diese Datei im Unterordner javascripts liegt, ist sie über die selbige URL erreichbar. Es spielt also keine Rolle, in welchem Unterverzeichnis die Datei gelegt wird, diese wird immer unter /assets/greetings.txt erreichbar sein. Das einzige was zu beachten ist, dass nach einem Verschieben der Datei ein Serverneustart erforderlich ist, um auf die Datei zuzugreifen.
Das Verzeichnis /app/assets ist nicht der einzige Ort, wo Assets abgelegt werden können. Wenn wir unter /lib einen asset Ordner erstellen, werden diese Files so behandelt, als wären sie im Haupt-Asset-Ordner. Das selbe passiert mit Dateien unter /vendor/assets.
Wenn du Assets hast, welche nicht spezifisch für die aktuelle Applikation sind, ist es besser, diese unter /lib oder /vendor zu plazieren. Wenn deine App z.B. jQuery plugin verwendet, welches von dir selbst nicht verwaltet oder entwickelt wurde, wäre es sinnvoll, diese unter /vendor/assets abzulegen. Von uns selbst verwaltete Assets, welche nicht Applikationspezifisch sind, wären unter /lib richtig aufgehoben.
Im Grunde genommen ist die Asset Pipeline eine Liste aus Loadpaths. Diese können mit dem Befehl Rails.application.config.assets.paths in der Console angezeigt werden.
Die Ausgabe zeigt jedes Verzeichnis unter app/assets, /lib/assets und /vendor/assets. Auffallend ist das Verzeichnis am Ende der Liste, welches vom jquery-rails gem kommt, welches wir in unserer Applikation includiert haben. Mit bundle open können wir nun das gem direkt im Editor öffnen.
Hierfür muss dein Pfad zum Texteditor mit der Umgebungsvariable BUNDLE_EDITOR oder EDITOR gesetzt sein. In der Verzeichnisstruktur des gem’s befindet sich der Ordner vendor/asset/javascripts. Dieser beinhaltet einige jQuery Dateien, welche ebenfalls durch die Asset Pipeline geladen werden.
So jetzt zurück zur application.js.
// This is a manifest file that'll be compiled into including all the files listed below. // Add new JavaScript/Coffee code in separate files in this directory and they'll automatically // be included in the compiled file accessible from http://example.com/assets/application.js // It's not advisable to add code directly here, but if you do, it'll appear at the bottom of the // the compiled file. // //= require jquery //= require jquery_ujs //= require_tree .
Diese JavaScript Datei beinhaltet eigentlich nur Kommentare, welche aber wichtig für die Asset Pipeline sind. Diese Syntax definiert das Manifest und wird intern von Sprockets verwaltet. Wird diese Datei nun angefragt, wird von Sprockets das Manifest ausgelesen. Anschließend werden alle angegebenen JavaScript Files zusammengesucht und in die application.js vor dem eigentlichen Code eingefügt. Bei require jquery (die Endung .js ist hier optional) wird nun in den Loadpaths die jquery.js gesucht. In unserem Fall liegt diese unter vendor/asset/javascripts des jquery-rails gem’s. Dies funktioniert auch mit CoffeeScript Dateien.
Mit require_tree . wird jede JavaScript oder CoffeeScript Datei in dem Home-Verzeichniss und den Unterverzeichnissen in die application.js eingefügt. Es kann ja auch sein, dass ihr einige Dateien garnicht in der application.js dabei haben wollt. Hierfür gibt es einige Wege um dies zu vermeiden. Einerseits könnte man mit require_directory nur die Dateien des Asset-Verzeichnisses laden. Nicht aber die Unterverzeichnisse. Andererseits können wir alle Dateien einzeln mit require inkludieren.
Auch Preprocessing funktioniert mit der Asset Pipeline. Hierfür erstellen wir die Datei greetings.txt.erb. Die Endung txt weist auf eine statische Datei hin. Mit der weiteren Endung .erb wird die Datei vorher vom erb-processor behandelt. So können wir also ERB Code in die Datei schreiben, welcher dann prozessiert wird.
hello world <%= 1 + 1 %>
Beim Ausführen im Browser mit /assets/greetings.txt bekommen wir die Ausgabe: hello world 2. Die Endung erb ist hierbei nicht notwendig. Dies funktioniert mit den SASS und CoffeeScript Dateien gleich. Wir können auch das Preprocessing verketten. Bei der Dateiendung .scss.erb wird die Datei zuerst vom Erb-Processor behandelt und anschließend vom Scss-Processor.
So das war mal ein kleiner Überblick über Features der Asset Pipeline. Es gibt noch einige Unterschiede über das Verhalten der Pipeline im Production-Mode. Hierfür starten wir den Server im Production-Mode:
rails s -e production
Wenn wir jetzt einen Blick in den Seitenquelltext unserer Applikation werfen, bekommen wir bei den Assets eine Ausgabe wie:
<link href="/assets/application-412fe22651f4486c51e54176003a9f57.css" media="screen" rel="stylesheet" type="text/css" /> <script src="/assets/application-3e3a5167191afa70c7b72440eee7dd40.js" type="text/javascript"></script>
Die Dateinamen der Assets beinhalten nun noch einen Hash, welcher für das Caching wichtig ist. Diese Methode eignet sich für das Caching besser, als der in Rails 3.0 noch verwendete Timestamp. Bei einem Blick in die application.js sehen wir nun, dass diese minimiert und komprimiert ist. Dies spart Ladezeiten ein.
Die Assets können auch mit folgendem Befehl vorkompiliert werden:
rake assets:precompile
Hierbei werden die Assets kompiliert und diese in den Ordner /public kopiert.
Ich hoffe, euch ist die Asset Pipeline nun etwas klarer. Für mehr Infos dazu besucht bitte den RailsGuide zur Asset Pipeline. Besonderen Dank geht an Ryan Bates und seiner Railscasts-Folge zur Asset Pipeline, die mir als Vorlage für den Post diente.
