ASCIIcasts - Full Episode Feed

Controller in Rails 3

Tue, 07 Sep 2010 19:05:26 +0000

Während die wichtigsten Änderungen an den Rails 3-Controllern im Hintergrund passiert sind, gibt es auch einige Änderungen an der öffentlichen API, mit welcher wir als Rails-Entwickler interagieren. Diese Episode wird einige der neuen Features behandeln.

Parameter Logging

Die erste Änderung betrifft den ApplicationController. In einer Rails 2 Applikation kann man bestimmte Parameter filtern, sodass sie nicht in Klartext im Logfile stehen, indem man die filter_parameter_logging-Methode, wie hier gezeigt, benutzt:

/app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  protect_from_forgery
  filter_parameter_logging :password
end

Diese Methode wurde in Rails 3 als deprecated markiert und sollte aus Anwendungen entfernt werden. Der Parameterfilter wird nun in der neuen config/application.rb-Datei konfiguriert. Der Parameterfiltercode, befindet sich am Ende der Datei.

/config/application.rb

# Configure sensitive parameters which will be filtered from the log file.
config.filter_parameters += [:password]

Diese Zeile wird standardmäßig zu einer neuen Rails 3 Anwendung hinzugefügt. Man vergisst leicht, das Filtern zu aktivieren, deswegen ist es ein hilfreiches Feature, dass es automatisch aktiviert ist. Natürlich wird es nur Passwortparameter filtern und muss abgeändert werden, wenn andere Parameter, zum Beispiel Kreditkartennummern, gefiltert werden sollen.

Redirect-Kurzformen

Als nächstes werfen wir ein Blick auf den ProductsController einer Store-Anwendung. Wenn wir uns den Code für die create-Methode anschauen, sehen wir, dass, sobald ein valides Produkt gespeichert wurde, die Action eine Flash-Nachricht erstellt und dann zur show-Action für das neu erstellte Produkt weiterleitet.

/app/controllers/products_controller.rb

def create
  @product = Product.new(params[:product])
  if @product.save
    flash[:notice] = "Successfully created product."
    redirect_to @product
  else
    render :action => 'new'
  end
end

Dies ist das ganz normale Verhalten in einem Controller und in Rails 3 können wir diese zwei Zeilen kombinieren, sodass die Flash-Nachricht ein Parameter der redirect_to-Methode wird.

/app/controllers/products_controller.rb

def create
  @product = Product.new(params[:product])
  if @product.save
    redirect_to @product, :notice => "Successfully created product."
  else
    render :action => 'new'
  end
end

Sowohl :notice als auch :alert funktionieren hier, jeder andere Flash-Nachrichtentyp muss in einem :flash-Hash eingebettet werden, was man aber eher selten benötigt. Dieses Feature wurde auch zu Rails 2.3.6 hinzugefügt, damit man diesen Kurzform auch mit einer aktuellen Rails 2 Version nutzen kann.

Die redirect_to-Methode nimmt auch ein Model-Objekt als Parameter. Ein Produkt-Model-Objekt als @product zu übergeben ist eine Kurzform für @product_path(@product) und wird in den Pfad der show-Action für das Produkt übersetzt. Wenn wir stattdessen zur edit-Seite dieses' Produkts weiterleiten wollen, können wir edit_product_path(@product) nutzen. Es gibt allerdings noch eine weitere nützliche Kurzform. Anstatt

redirect_to edit_product_path(@product)

können wir es als Array schreiben:

redirect_to [:edit, @product]

Dies wird in denselben edit_product_path übersetzt, aber mit etwas weniger Code. Wie die obige :notice-Option, funktioniert das auch in einer neueren Version von Rails 2. Diese Kurzform funktioniert auch mit verschachtelten Ressourcen, somit können wir, wenn ein Produkt zu einer Kategorie gehört, folgendermaßen weiterleiten:

redirect_to [@category, @product]

Diese Array-Technik funktioniert überall wo man eine URL generieren kann und kann genauso gut in dem View-Code einer link_to-Methode oder in Controllern benutzt werden.

Permanente Cookies

Das nächste neue Feature sind permanente Cookies. Angenommen ein Benutzer erstellt ein neues Produkt, dann wollen wir die Produkt-ID in einem Cookie speichern. Wir können die cookies-Methode dafür benutzen:

/app/controllers/proucts_controller.rb

def create
  @product = Product.new(params[:product])
  if @product.save
    cookies[:last_product_id] = @product.id
    redirect_to @product, :notice => "Successfully created product."
  else
    render :action => 'new'
   end
end

Dieser Code erstellt ein Session Cookie, welcher nur solange hält, wie der Benutzer sein Browserfenster offen hält. Um einen Cookie mit einem speziellem Ablauf-Datum in Rails 2 zu erstellen, müssten wir den Wert in einen Hash umwandeln und ein explizites Ablaufdatum setzen:

cookies[:last_product_id] = { :value => @product_id, :expires => 1.month.from_now }

In Rails 3 (und ab Rails 2.3.6) können wir die neue cookies.permanent-Methode benutzen um einen Cookie mit langer Ablaufzeit zu erstellen.

cookies.permanent[:last_product_id] = @product.id

Wir können außerdem gesignte Cookies auf diese Art erstellen, doch darauf gehen wir jetzt nicht im Detail ein. Es gibt einen sehr lesenswerten Blogeintrag von Pratik Naik zu diesem Thema. Im Wesentlichen nutzt man die cookies.permanent.signed-Methode um einen verschlüsselten Cookie zu generieren und ihn später zu lesen. Zu beachten ist, dass man ein cookie_verifier_secret brauchen, damit die Anwendung funktioniert.

`respond_with` benutzen

Die letzte neue Sache in dieser Episode, ist wahrscheinlich die bedeutendste Ergänzung an Rails 3 Controllern: respond_with. Wir werden das demonstrieren, indem wir ein REST-Service über ein XML-Interface zu unserem ProductsController hinzufügen. Das bedeutet, dass jede Action des Controllers zusätzlich zu seiner HTML Antwort eine XML-Antwort zurückgeben muss.

In einer Rails 2 Applikation würden wir das mit der respond_to-Methode in jeder Action implementieren:

/app/controllers/products_controller.rb

def index
  @products = Product.all
  respond_to do |format|
    format.html
    format.xml { render :xml => @products }
  end
end

In dem respond_to-Block legen wir für alle Formate fest, wie die Action reagieren soll. Für eine XML-Anfrage soll sie, zum Beispiel, den @products-Array als XML darstellen. Diese Vorgehensweise kann schnell unhandlich werden, wenn wir dies für jede Action im Controller machen müssen.

In Rails 3 können wir diesen Code mit einem Aufruf von respond_with ersetzen, dem wir das bestimmte Objekt mitgeben, in diesem Fall der Array von Produkten. Damit respond_with funktioniert, müssen wir die "Schwester"-Klassenmethode respond_to benutzen, um festzulegen, auf welche MIME-Typen der Controller reagieren soll und somit respond_with weiß, welche Formate es in jeder Action zurückgeben kann.

/app/controllers/products_controller.rb

class ProductsController < ApplicationController
  respond_to :html, :xml

  def index
    @products = Product.all
    respond_with @products
  end

  # Other methods
end

Wenn wir unsere Änderungen testen wollen und uns die Produktindexseite im Browser anschauen, sehen wir, das die HTML-index-Action so angezeigt wird, wie wir es erwartet haben.

Und wenn wir .xml an die URL anhängen, bekommen wir die XML-Antwort.

Wie funktioniert nun die respond_with-Methode genau? Für einen einfachen GET-Request (z.B. index) sucht es nach einer View-Datei zur Darstellung des passenden MIME-Typs, beispielsweise eine .html.erb-Datei, und rendert es. Falls respond_with keinen View finden kann, versucht es eine Methode wie to_xml (oder z.B. to_json) aufzurufen, um das übergebene Objekt im passenden Format darzustellen.

Mit diesem Wissen können wir diese respond_with-Zeile einfach in die show- und die new-Methode kopieren.

/app/controller/products_controller.rb

def show
  @product = Product.find(params[:id])
  respond_with @product
end

def new
  @product = Product.new
  respond_with @product
end

Die create-Action ist etwas komplizierter, denn sie enthält HTML-spezifischen Code wie redirect_to und render. Wir wollen diese Methoden nicht in einem XML-Response verwenden. Und wir können beide vermeiden, indem wir sie einfach entfernen und stattdessen einen Aufruf zu respond_with hinzufügen. Die Action sieht jetzt wie folgt aus:

/app/controllers/products_controller.rb

def create
  @product = Product.new(params[:product])
  if @product.save
    cookies[:last_product_id] = @product.id
    flash[:notice] = "Successfully created product."
  end
  respond_with(@product)
end

Wir können das machen, weil respond_with überprüft, ob das übergebene Objekt valide ist oder nicht, und je nachdem rendert oder redirectet. Jetzt können wir respond_with zu den anderen Actions im Controller hinzufügen und dabei wieder jeden HTML-spezifischen Code entfernen. Danach sieht unsere Controller-Code etwa so aus:

/app/controllers/products_controller.rb

class ProductsController < ApplicationController
  respond_to :html, :xml

  def index
    @products = Product.all
    respond_with @products
  end

  def show
    @product = Product.find(params[:id])
    respond_with @product
  end

  def new
    @product = Product.new
    respond_with @product
  end

  def create
    @product = Product.new(params[:product])
    if @product.save
      cookies[:last_product_id] = @product.id
      flash[:notice] = "Successfully created product."
    end
    respond_with(@product)
  end
  
  def edit
    @product = Product.find(params[:id])
    respond_with(@product)
  end
  
  def update
    @product = Product.find(params[:id])
    if @product.update_attributes(params[:product])
      flash[:notice] = "Successfully updated product."
    end
    respond_with(@product)
  end

  def destroy
    @product = Product.find(params[:id])
    @product.destroy
    flash[:notice] = "Successfully destroyed product."
    respond_with(@product)
  end
end

Die respond_with-Methode kann etwas verwirrend sein, deswegen hier eine kleine Zusammenfassung:

Für einen GET-Request sucht respond_with zuerst nach einem View, welcher zu diesem spezifischen Format passt. Wenn es einen findet, rendert er den View; wenn nicht, ruft es to_xml (oder was auch immer für ein Format angefordert wurde) auf dem übergebenen Objekt auf.

Für jeden anderen Requesttyp prüft respond_with, ob das übergebene Objekt Errors hat. Wenn es welche hat, wird der passende View gerendert (z.B. new für die create-Action und edit für update). Falls es keine gibt, redirectet es zu der objektspezifischen Seite (z.B. die show-Action).

Wird können es ausprobieren, indem wir eines unserer Produkte bearbeiten.

Wenn wir den "Update Product" Button drücken, wird die update-Action aufgerufen und respond_with führt eine Weiterleitung zur Seite des Produktes durch. Das Produkt wurde erfolgreich aktualisiert.

Genauso klappt der "Destroy" Link, wir werden zur Indexseite weitergeleitet.

Wenn das Standardverhalten von respond_with für einige Teile unserer Anwendung nicht mehr ausreicht, können wir es für bestimmte Actions anpassen. Zum Beispiel, wenn wir wollen, dass bei dem Update eines Produktes, die Anwendung nicht zur show-Action, sondern zur index-Action weiterleiten soll. In diesem Fall können wir respond_with eine location-Option übergeben:

/app/controllers/products_controller.rb

def update
  @product = Product.find(params[:id])
  if @product.update_attributes(params[:product])
    flash[:notice] = "Successfully updated product."
  end
  respond_with(@product, :location => products_url)
end

Wir können auch die jeweiligen Formate überschreiben, indem wir respond_with einen Block übergeben, genauso wie wir es mit der respond_to-Methode machen würden. Wenn wir zum Beispiel einfach nur etwas Text für das XML-Format der edit-Action darstellen wollen, können wir es so machen:

/app/controllers/products_controller.rb

def edit
  @product = Product.find(params[:id])
  respond_with(@product) do |format|
    format.xml { render :text => "I'm XML!" }
  end
end

Wenn wir die XML-Version der edit-Seite besuchen, sehen wir den Text.

Sollte man letztendlich eine komplett eigene Anpassung benötigen, kann man eine eigene Responder-Klasse übergeben. Auf diese Weise wird der Controller alles an diese Klasse weiterreichen und wir können das Verhalten des Responses frei anpassen.

respond_with(@product, :responder => MyResponder)

Wenn man wissen möchte, wie eine Responder-Klasse erstellte wird, sollte man sich die in Rails 3 eingebaute Responder-Klasse anschauen. Der Code ist recht einfach zu lesen und gut dokumentiert und man bekommt eine bessere Vorstellung davon, wie der Responder funktioniert.

Das ist alles für diese Episode. Wie man gesehen hat, ist respond_with eine wirklich zweckmäßige Herangehensweise, viele Formate zu bewältigen. Sollte man aber feststellen, dass man es zu stark anpasst, ist es wahrscheinlich einfacher, respond_with nicht zu verwenden oder eine eigene Responder-Klasse zu schreiben.

Unobtrusive JavaScript

Tue, 30 Mar 2010 17:41:09 +0000

In unserer Serie über die neuen Features von Rails 3 betrachten wir in dieser Episode das Thema dezentes bzw. unaufdringliches JavaScript (unobtrusive Javascript). Dezentes JavaScript bedeutet, JavaScript- und HTML-Code weitestgehend zu trennen. Im ausgelieferten HTML-Dokument sollten also nach Möglichkeit keine oder so gut wie keine JavaScript-Anweisungen stehen, sondern nur in externen Dateien. Dies funktioniert analog wie die Trennung von Struktur (HTML) und Design (CSS). Bevor wir zur eigentlichen Anwendung in Rails kommen, hier ein kleines Beispiel anhand eines einfachen HTML-Dokuments.

Der nachfolgende Screenshot zeit eine Webseite mit einem Link darauf. Sobald der Link aufgerufen wird, wird ein JavaScript alert ausgeführt, der “Hello world!” ausgibt.

Der HTML-Code für diese Seite sieht so aus::

<!DOCTYPE html>
<html>
  <head>
    <title>UJS Example</title>
  </head>
  <body>
    <h1><a href="#" onclick="alert('Hello world!'); return false;">Click Here</a></h1>
  </body>
</html>

In dieser Seite haben wir direkt im HTML-Dokument im onclick-Attribut JavaScript-Code stehen. Solche Anweisungen sind also keineswegs dezent/unaufdringlich (unobtrusive eben), was nicht gerade ideal ist, da wir Verhalten und Inhalt miteinander vermischen. In den 90er Jahren wurden Webseiten sehr häufig mit <font>-Tags gestaltet, um Schriftart und -aussehen von Texten einzustellen, da es damals noch kein CSS gab. Daraus resultierte automatisch, dass man, wenn man beispielsweise die Größe aller mit <p> deklarierten Absätze verändern wollte, nicht selten hunderte über mehrere Dateien verteilte Änderungen durchführen musste. Als die Browser endlich anfingen, CSS zu unterstützen, konnte man das Styling der Seite in Stylesheets auslagern und nur noch die Struktur und den Inhalt der Seite im HTML belassen. So wurde es deutlich einfacher, das Aussehen einer Webseite einheitlich anzupassen.

Dasselbe gilt für JavaScript: Viele kleine Codeschnipsel innerhalb des HTML-Dokuments, meistens in Attributen wie onclick, vermischt verschiedene Zuständigkeiten und erschwert die Wartung nicht unerheblich. Das Herauslösen von JavaScript in eigenständige Dateien, die im head-Bereich von HTML-Dokumenten eingebunden werden, vermeidet Code-Duplikate, ermöglicht einfache Refactorings und erleichtert die Erstellung von und die Fehlersuche in komplexen Webanwendungen.

Nur wie machen wir den JavaScript-Code in unserem einfachen Beispiel unaufdringlich? Der zentrale Schritt ist das Verschieben des Codes aus dem onclick-Attribut in eine eigene Datei und die Verwendung eines JavaScript-Frameworks, hier jQuery, um die Anweisungen mit den richtigen HTML-Elementen zu verbinden. Zeigen wir zuerst die umgewandelte Datei und beleuchten dann die durchgeführten Änderungen.

<!DOCTYPE html>
<html>
  <head>
    <title>UJS Example</title>
    <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js" type="text/javascript" charset="UTF-8"></script>
    <script type="text/javascript"charset="UTF-8">
      $(function () {
        $('#alert').click(function () {
          alert('Hello, world!');
          return false;
        })
      });
    </script>
  </head>
  <body>
    <h1><a href="#" id="alert">Click Here</a></h1>
  </body>
</html>

Zuallererst fällt auf, dass wir die Anweisungen doch nicht in eine eigene Datei verschoben haben. Dies dient hier nur der besseren Übersicht, da sich die Änderungen so leichter darstellen lassen.

Das a-Element wurde um sein onclick-Attribut erleichtert und hat stattdessen ein id-Attribut dazubekommen, damit wir dieses Element leicht vom jQuery-Code aus adressieren können. Weiterhin haben wir im head-Bereich der Seite die jQuery-Bibliothek eingebunden und darunter die eigentlichen Anweisungen (die selbstverständlich in einer eigenen Datei stehen sollten und auch mit Hilfe eines script-Tags eingebunden werden sollten). Das Skript beginnt mit dem Aufruf der $-Methode von jQuery, der eine anonyme Funktion als Parameter übergeben wird. Diese Funktion wird ausgeführt, sobald das DOM der Seite geladen wird und enthält die jQuery-Anweisungen, die anhand der id das a-Element finden und eine Funktion an dessen click-Event anhängen. Diese Funktion wiederum führt den eigentlichen alert-Aufruf durch und gibt false zurück, damit der Browser dem Link nicht folgt.

Wenn wir die Seite neu laden, verhält sie sich immer noch genau so wie zuvor: Der alert wird angezeigt, sobald der Link angeklickt wird.

Auf den ersten Blick drängt sich der Eindruck auf, dass man hierfür unverhältnismässig viel Arbeit investieren muss, um die Trennung durchzuführen, doch dieses simple Beispiel demonstriert schlicht und ergreifend auch nicht die wirklichen Vorteile, die sich mit dezentem JavaScript ergeben. Immerhin haben wir eine Zeile JavaScript-Code genommen und sechs daraus gemacht. Wie gesagt ist dieses Beispiel auch nicht dafür geeignet, um die Vorteile aufzuzeigen, sondern dient lediglich der Demonstration, wie die Technik angewendet wird und wo sich Unterschiede ergeben. Die Vorzüge von unaufdringlichem Code werden erst wirklich deutlich, wenn eine Anwendung viel mehr und komplexeres JavaScript einsetzt, da sich Code-Duplikate viel leichter identifizieren und beheben lassen, wenn man den gesamten Code an einer Stelle hat, anstatt überall in der Anwendung nach einzelnen Fragmenten suchen zu müssen.

Ein großes Problem mit dieser Technik ist allerdings, dass der Code gewöhnlich in einer statischen JavaScript-Datei gespeichert ist. Wie kann man also dynamischen, serverseitigen Inhalt in das Skript einfügen, wo es ja nicht mehr inline im eigentlichen View-Code steht?

In HTML 5 kann man so genannte custom data attributes verwenden, um zu einem bestimmten Element gehörige Daten in der Seite speichern kann. Diese Attribute sind genau wie alle anderen HTML-Attribute, nur ihr Name beginnt immer mit data-. Um beispielsweise die Nachricht, die angezeigt werden soll, wenn der Link angeklickt wird, von der Rails-Applikation aus dynamisch festzulegen, schreiben wir unseren Code um:

<a href="#" id="alert" data-message="Hello from UJS">Click Here</a>

In the JavaScript we can then alter the alert to show the text from our new attribute:

$(function () {
  $('#alert').click(function () {
    alert(this.getAttribute('data-message'));
    return false;
   })
});

Nach dem Neuladen der Seite sehen wir die Nachricht aus dem data-Attribut.

Wie Rails 3 `data`-Attribute verwendet

Rails 3 nutzt diese custom data attributes bei der Umsetzung von unaufdringlichem JavaScript-Code, indem Daten an JavaScript übergeben werden können. Betrachten wir nun, wie sich das in einer Rails-Anwendung einsetzen lässt. Unser Beispiel ist eine einfache eCommerce-Anwendung, die eine Liste von Produkten hat, die durchsucht werden kann. Darüber hinaus gibt es noch Links zum Bearbeiten und Löschen von Produkten. Die Löschen-Links scheinen nicht mehr richtig zu funktionieren:

Dies ist ein typisches Problem mit Rails 3 Anwendungen. Wenn Sie gerade eine neue Applikation aufsetzen oder von einer früheren Version von Rails portieren, werden Sie feststellen, dass manche Stellen der Anwendung, an denen JavaScript verwendet wird, nicht mehr funktionieren!

Der view-Code der den “Destroy”-Link erzeugt ist ein normaler link_to_method-Aufruf mit einer :confirm-Option, die einen JavaScript-confirm-Dialog anzeigt und mit einer :method-Option, die auf :delete gesetzt ist, damit der Request nicht als einfacher GET-Request abgesetzt wird, sondern mit dem DELETE-Verb.

/app/views/products/show.html.erb

<%= link_to "Destroy", @product, :confirm => "Are you sure?", :method => :delete %>

What’s interesting here is the HTML source that this code generates:

<a href="/products/8" data-confirm="Are you sure?" data-method="delete" rel="nofollow">Destroy</a>

In Rails 2 wurde durch jeden link_to-Aufruf, der als Resultat einen Link auf einen POST-, DELETE- oder PUTRequest haben sollte, jede Menge inline-JavaScript-Code erzeugt, der den confirm-Dialog auslöste und den entsprechenden Request durchführen sollte. Im Vergleich dazu ist der von Rails 3 ausgelieferte HTML-Code erheblich übersichtlicher und durch die Nutzung von HTML 5 lassen sich auch mehrere Attribute erzeugen, beispielsweise ein data-confirm-Attribut, das die Bestätigungsnachricht enthält und ein weiteres data-method, das die eigentliche Methode beinhaltet.

Der Grund, warum die Links nicht funktionieren ist, dass bisher die benötigten JavaScript-Dateien im head-Bereich der Seite geladen werden und der Link daher einen normalen GET-Request auslöst, da kein JavaScript das click-Event verändert hat.

Um dieses Problem zu lösen, fügt man einfach eine weitere Zeile in den head-Bereich ein:

/app/views/layouts/application.html.erb

<%= javascript_include_tag :defaults %>
<%= csrf_meta_tag %>

Die erste Zeile sollte bekannt sein. Sie veranlasst, dass die Standard-JavaScript-Dateien für Rails-Anwendungen geladen werden. Die Zweite jedoch erzeugt zwei meta-Tags, die das authenticity-Token enthalten, die nötig sind, um DELETE-Requests durchführen zu können. Laden wir also die Seite neu und betrachten wir den ausgelieferten HTML-Code, um die Ausgaben dieser beiden Zeilen zu sehen:

<script src="/javascripts/prototype.js?1268677667" type="text/javascript"></script>
<script src="/javascripts/effects.js?1268677667" type="text/javascript"></script>
<script src="/javascripts/dragdrop.js?1268677667" type="text/javascript"></script>
<script src="/javascripts/controls.js?1268677667" type="text/javascript"></script>
<script src="/javascripts/rails.js?1268677667" type="text/javascript"></script>
<script src="/javascripts/application.js?1268677667" type="text/javascript"></script>
<meta name="csrf-param" content="authenticity_token"/>
<meta name="csrf-token" content="9ImdFvbeW7ih9oKqBDQ3O889q/hJ1q5uajpT4DFDAoA="/>

In der Seite laden wir jetzt also alle JavaScript-Dateien, die unsere Applikation braucht und haben zusätzlich zwei meta-Tags, die nötig sind, um cross-site request forgery zu unterbinden. Dies versichert, dass PUT- und DELETE-Requests tatsächlich vom richtigen Benutzer kommen und nicht einer anderen Seite oder von einem Hacker.

Sobald diese Vorbedingungen erfüllt sind, sollte der Link endlich wie erwartet funktionieren:

Hinzufügen von AJAX-Funktionalität zum Suchfeld

Als Nächstes verändern wir das Suchformular auf der index-Seite so, dass es beim Abschicken einen AJAX-Aufruf verwendet anstelle des bisher verwendeten GET-Requests. Der Code für das index-View lautet:

/app/views/products/index.html.erb

<% title "Products" %>

<% form_tag products_path, :method => :get do %>
  <p>
    <%= text_field_tag :search, params[:search] %>
    <%= submit_tag "Search", :name => nil %>
  </p>
<% end %>

<div id="products">
  <%= render @products %>
</div>

<p><%= link_to "New Product", new_product_path %></p>

Das Formular, das hier verwendet wird, nutzt die Technik, die in Episode 37 vorgestellt wurde. In früheren Versionen von Rails musste man, um AJAX-Funktionalität zu erreichen, den form_tag durch einen form_remote_tag ersetzen. Diese Methode generiert allerdings sehr viel inline-JavaScript, was wir jetzt ja gerade vermeiden wollen.

Viele der remote-Hilfsfunktionen ist nicht mehr verfügbar in Rails 3. Um sie wieder freizuschalten, könnte man das Prototype Legacy Helper Plugin installieren, doch wir gehen hier den neuen Rails-3-Weg.

Als Alternative zum form_remote_tag bleiben wir beim form_tag und fügen einen neuen Parameter :remote hinzu.

/app/views/products/index.html.erb

<% form_tag products_path, :method => :get, :remote => true do %>
  <p>
    <%= text_field_tag :search, params[:search] %>
    <%= submit_tag "Search", :name => nil %>
  </p>
<% end %>

Dieser neue Parameter kann auch mit anderen Hilfsfunktionen wie link_to, button_to und form_for verwendet werden. Laden wir die Seite neu und betrachten, wie der neue Formular-Code funktioniert:

<form action="/products" data-remote="true" method="get">  <p>
    <input id="search" name="search" type="text" />
    <input type="submit" value="Search" />
  </p>
</form>

Das Formular-Element ist dasselbe wie zuvor, hat aber ein neues data-remote-Attribut. Es gibt kein inline-JavaScript, da das neue Attribut allein schon genug ist, um mit Hilfe des Codes in rails.js einen AJAX- anstelle eines GET-Requests auszulösen.

Als Nächstes müssen wir noch den Code schreiben, der die Antwort des AJAX-Aufrufs verarbeiten kann. Die Liste mit den Produkten ist in einem div-Container mit der ID products, also müssen wir einfach den Inhalt dieses div-Elements aktualisieren, um die angeforderten Suchergebnisse anzuzeigen. Das Formular wird zur index-Aktion des ProductControllers abgeschickt, also müssen wir einfach ein neues view-Template index.js.erb erzeugen, das JavaScript-Anfragen beantworten kann.

Wir können in dieser Datei beliebigen JavaScript-Code schreiben, der ausgeführt wird, sobald er beim Browser angekommen ist. Der Code zum Aktualisieren des Inhalts des products-Containers sieht beispielsweise so aus:

/app/views/products/index.js.erb

$("products").update("<%= escape_javascript(render(@products))%>");

When we reload the page and submit the form the search will be made with an AJAX call and we can see this as the page’s URL doesn’t change when the search is made.

Also kann man in Rails 3 sehr einfach unaufdringlichen JavaScript-Code für AJAX-Aufrufe schreiben, indem man den :remote-Parameter verwendet und ein JavaScript-Template für die entsprechende Aktion festlegt.

Auswechseln des Frameworks

Zu guter letzt demonstrieren wir noch, wie man die verwendeten JavaScript-Frameworks, die in unserer Applikation verwendet werden, gegen andere austauschen kann. Unsere Applikation verwendet momentan Prototype, das standardmässig bei Rails dabei ist, doch was, wenn wir stattdessen jQuery verwenden möchten?

Zuerst müssen wir die Einbindung im Hauptlayout

/app/views/layouts/application.html.erb

<%= javascript_include_tag :defaults %>

mit der folgenden Anweisung ersetzen:

/app/views/layouts/application.html.erb

<%= javascript_include_tag "http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js", "jquery.rails.js" %>

Die erste Datei in er Liste ist die neueste jQuery-Version frisch vom Google-Server. Das alleine genügt allerdings noch nicht, da wir ein Äquivalent zur rails.js-Datei benötigen, die wir schon zuvor verwendet haben, um das Rails-spezifische JavaScript zu verarbeiten. Auf Github gibt es das offizielle jquery-ujs Projekt. Es beinhaltet eine rails.js-Datei, die heruntergeladen werden und in unseren Projekten verwendet werden kann. Wir haben die Datei heruntergeladen und im Ordner /public/javascripts abgelegt und es in jquery.rails.js umbenannt.

Jetzt müssen wir noch sämtliche Skripte, die in unserer Anwendung vorkommen, von Prototype auf jQuery umschreiben, da sich die Syntax der beiden Frameworks unterscheidet. Dies bringt also ein paar Änderungen in index.js.erb mit sich, beispielsweise #products als Selektor für das div-Element anstelle von products oder das Austauschen der update-Methode von Prototype durch die jQuery-Methode html.

/app/views/products/index.js.erb

$("#products").html("<%= escape_javascript(render(@products))%>");

Unsere Anwendung wird sich jetz exakt so verhalten wie zuvor, nur dass unter der Motorhaube jQuery anstatt Prototype verwendet wird.

Stilles Zurückfallen auf nicht-JavaScript-Funktionalität

Wenn ein Benutzer unsere Anwendung verwenden möchte, dessen Browser kein JavaScript aktiviert hat, wird sich das Suchformular wie gehabt verhalten und beim Abschicken einen normalen GET-Aufruf ausführen. Löschen von Produkten wird jedoch nicht funktionieren. Dies ist ein geläufiges Problem, da Rails JavaScript nutzt, um DELETE oder PUT zu simulieren, weil HTML-Links keine anderen als GET-Requests auslösen können. Eine mögliche Lösung ist, den Link mit einem Button zu ersetzen, indem man button_to verwendet. Dummerweise können Buttons nur schwer in das Layout der Seite eingefügt werden, weswegen in den meisten Fällen nur ein Link in Frage kommt. Eine weitere Technik wurde bereits in Episode 77 gezeigt, wobei eine eigene Bestätigungs-Seite gezeigt wird, bevor die eigentliche Löschung vorgenommen wird.

Active Record Queries in Rails 3

Mon, 01 Mar 2010 23:14:38 +0000

Im Verlauf der letzten beiden Episoden haben wir Ihnen gezeigt, wie Sie Ihren Computer für Rails 3 vorbereiten und eine neue Rails 3 Applikation erzeugen können. In dieser Folge werden wir einige der neuen Features betrachten. Wir beginnen mit ActiveRecord, der jetzt ein neues Interface anbietet, um Datenbankanfragen durchzuführen. Pratik Naik hat sich diesem Thema kürzlich in einem Beitrag in seinem Blog ausführlich gewidmet, der durchaus einen Blick wert ist.

Ein paar einfache Beispiele

Zu Beginn zeigen wir Ihnen ein paar Beispiele von alten ActiveRecord-find Aufrufen und übersetzen diese in das neue Format. Zu diesem Zweck verwenden wir eine einfache Rails Applikation mit zwei Models: Article und Comment, wobei gilt: Article: has_many :comments.

Der erste find-Aufruf gibt die zehn zuletzt veröffentlichen Artikel zurück:

Article.find(:all, :order => "published_at desc", :limit => 10)

Grundlegend sieht man sich beim übersetzen von ActiveRecord Queries in das neue Rails 3 Format den Hash mit Optionen an, die an find übergeben werden und ersetzt jeweils einen Teil mit einem äquivalenten Methodenaufruf. An Stelle des find-Aufrufs von oben kann man schreiben:

Article.order("published_at desc").limit(10)

Wie Sie sehen, ist die Übersetzung sehr einfach und bietet eine insgesamt schönere Syntax.

Die Optionen aus dem alten Hash lassen sich direkt in die neuen Methoden übertragen, wie das nächste Beispiel zeigt.

Article.find(:all, :conditions => ["published_at <= ?", Time.now], :include => :comments)

Es gibt nur zwei tatsächliche Ausnahmen, die im nachfolgenden Beispiel verwendet wurden. Der soeben genannte find-Aufruf liefert alle Artikel, deren Veröffentlichungszeitpunkt in der Vergangenheit liegt inklusive der dazugehörigen Kommentare. In Rails 3 wird daraus:

Article.where("published_at <= ?", Time.now).includes(:comments)

An Stelle von :conditions können wir jetzt die where-Methode verwenden, der wir dieselben Argumente übergeben. Sie können als Array oder einzeln übergeben werden. Um assoziierte Einträge zu bekommen, verwendet man anstatt :include jetzt die (um ein s erweiterte) includes-Methode. Alle anderen Optionen, die wir bisher an find übergeben haben, wurden zu Methoden mit den gleichen Namen wie die jeweilige Option selbst.

Unser letztes Beispiel sucht den neuesten Artikel.

Article.find(:first, :order => "published_at desc")

Unter Verwendung der neuen Rails 3 Syntax wird daraus:

Article.order("published_at desc").first()

Beachtenswert ist hier, dass wir first erst am Ende der Methodenverkettung aufrufen.

Da wir in absteigender Reihenfolge suchen, könnten wir die Anweisung auch äquivalent umwandeln zu:

Article.order("published_at").last()

Das Ergebnis wäre die gleiche Datenbankanfrage, doch mit knapperem Code.

In Rails 3 können wir entweder die alten find-Methoden oder die neuen Rails 3 Methoden. In Rails 3.1 jedoch werden die alten Methoden als veraltet markiert und mit Rails Version 3.2 werden sie vollends entfernt werden. Es ist daher notwendig, alle finds in Ihren Applikationen auf die neue Syntax zu migrieren, damit sie mit zukünftigen Versionen von Rails 3 kompatibel sein werden.

An dieser Stelle werden Sie sich vielleicht fragen, was genau der Grund für diese neue Syntax ist - vor Allem, weil mit ihrer Einführung sehr viele existierende Rails-Applikationen nicht mehr funktionieren werden, wenn die Umstellung stattfindet. Der Grund für diese drastische Neuerung liegt beim mächtigen lazy loading.

Lazy Loading

Um lazy loading zu demonstrieren, verwenden wie die Konsole unserer Applikation. Wenn wir alle Artikel abfragen, bekommen wir wie erwartet ein Array mit allen Artikeln. Im Beispiel haben wir drei Artikel in unserer Datenbank.

ruby-1.9.1-p378 > Article.all => [#<Article id: 1, name: "It's Ancient", published_at: nil, hidden: false, 
created_at: "2010-02-22 20:35:42", updated_at: "2010-02-22 20:35:42">, 
#<Article id: 2, name: "Can't See Me", published_at: nil, hidden: false, 
created_at: "2010-02-22 20:37:03", updated_at: "2010-02-22 20:37:03">, 
#<Article id: 3, name: "To the Future!", published_at: nil, hidden: false, 
created_at: "2010-02-22 20:38:17", updated_at: "2010-02-22 20:38:17">]

Wenn wir alle Artikel alphabetisch sortiert wollen, verwenden wir die order-Methode:

ruby-1.9.1-p378 > articles = Article.order("name")
 => #<ActiveRecord::Relation:0x00000101669b90 @table=#<Arel::Table:0x000001023e9af8 
@name="articles", @options={:engine=>#<Arel::Sql::Engine:0x000001023a15c8 @ar=ActiveRecord::Base,
@adapter_name="SQLite">}, @engine=#<Arel::Sql::Engine:0x000001023a15c8 @ar=ActiveRecord::Base,
@adapter_name="SQLite">, …

Anstatt einer Liste von Artikeln haben wir diesmal ein ActiveRecord::Relation Objekt zurückbekommen. Dieses Objekt speichert Informationen über unsere Suche, die tatsächliche Anfrage wurde aber noch nicht durchgeführt. Dies ist die Bedeutung von lazy loading in diesem Kontext: Die Daten werden erst abgefragt, wenn es sein muss! Die Anfrage an die Datenbank wird erst durchgeführt, wenn wir explizit eine Datenmenge anfordern (z.B. mit each, wenn wir alle Artikel auf einmal oder nur den ersten Artikel anfragen würden):

ruby-1.9.1-p378 > articles.first
 => #<Article id: 2, name: "Can't See Me", published_at: nil, hidden: false, 
created_at: "2010-02-22 20:37:03", updated_at: "2010-02-22 20:37:03">

Betrachten wir nun, inwiefern sich das auf unsere Applikation anwenden lässt. Wir haben ein Scaffold für Article erzeugen lassen, also haben wir auch einen ArticlesController mit den üblichen sieben Aktionen. In der index-Aktion wird Article.all verwendet, um alle Artikel auf einmal abzufragen:

/app/controllers/articles_controller.rb

def index
  @articles = Article.all

  respond_to do |format|
    format.html # index.html.erb
    format.xml  { render :xml => @articles }
  end
end

Verwenden wir eine der neuen Methoden wie beispielsweise order, um die Artikel nach dem Namen zu sortieren, wird an Stelle des Arrays mit allen Artikeln ein ActiveRecord::Relation Objekt in @articles gespeichert. Das hat zur Folge, dass die eigentliche Datenbankanfrage nicht im Controller, sondern im View durchgeführt wird.

/app/views/articles/index.html.erb

<% @articles.each do |article| %>
  <tr>
    <td><%= article.name %></td>
    <td><%= article.published_at %></td>
    <td><%= article.hidden %></td>
    <td><%= link_to 'Show', article %></td>
    <td><%= link_to 'Edit', edit_article_path(article) %></td>
    <td><%= link_to 'Destroy', article, :confirm => 'Are you sure?', :method => :delete %></td>
  </tr>
<% end %>

Wenn wir jetzt die Index-Seite aufrufen, werden die Artikel in alphabetischer Reihenfolge dargestellt.

Sehr angenehm fällt auf, dass fragment caching mithilfe der cache-Methode im View sich jetzt deutlicher auswirken wird, da der üblicherweise langsame Datenbankzugriff nur dann ausgeführt werden wird, wenn er wirklich notwendig ist.

Die neue Syntax macht es darüber hinaus auch einfacher, komplexere Suchbedingungen zu vereinen. Nehmen wir an, wir wollen die Artikel filtern, so dass nur die versteckten angezeigt werden, wenn wir hidden=1 als Parameter in der URL übergeben. Dies lässt sich leicht verwirklichen, indem wir den Code in der index-Aktion wie folgt verändern:

/app/controllers/articles_controller.rb

def index
  @articles = Article.order('name')
    
  if params[:hidden]
    @articles = @articles.where(:hidden =>(params[:hidden] == "1"))
  end

  respond_to do |format|
    format.html # index.html.erb
    format.xml  { render :xml => @articles }
  end
end

Ist ein hidden-Parameter vorhanden und hat er den Wert 1, wird eine zusätzliche where-Methode an unsere Suche angehängt, so dass die Suche nur noch die versteckten Artikel anzeigen wird. Sobald wir den entsprechenden Parameter an die URL anhängen und neu laden, sehen wir nur noch die versteckten Artikel.

Übergeben wir hingegen 0, bekommen wir nur die sichtbaren Artikel zu sehen.

Die Möglichkeit, verschiedenste Suchmethoden aneinander zu hängen, eröffnet Wege, mit sehr einfachem Code deutlich komplexere Datenbankabfragen zu formulieren, die auch erst dann tatsächlich ausgeführt werden, wenn die Daten benötigt werden.

Named Scopes

Als Nächstes werden wir einige der Änderungen zu Named Scopes in Rails 3 betrachten. Als Beispiel dient uns unser Model Article mit zwei Named Scopes, einer für die sichtbaren Artikel und einer für die veröffentlichten.

/app/models/article.rb

class Article < ActiveRecord::Base
  named_scope :visible, :conditions => ["hidden != ?", true]
  named_scope :published, lambda { {:conditions => ["published_at <= ?", Time.zone.now]} }
end

Diese Scopes sind im Stil von Rails 2 formuliert, doch in Rails 3 ist die Vorgehensweise leicht unterschiedlich. Der erste Unterschied liegt in der Benennung der Funktion: Sie heißt jetzt nicht mehr named_scope, sondern einfach nur noch scope. Darüber hinaus werden die Optionen nicht mehr als Hash übergeben sondern genau wie beim Wechsel von find als einzelne Methoden. Genau wie wir die neuen find-Methoden verwendet haben, verwenden wir hier where an Stelle von :conditions. Die Syntax für Named Scopes in Rails 3 sieht also so aus:

/app/models/article.rb

class Article < ActiveRecord::Base
  scope :visible, where("hidden != ?", true)
  scope :published, lambda { where("published_at <= ?", Time.zone.now) }
end

Ein weiteres neues Feature ist die Möglichkeit, scopes aufeinander aufzubauen. Wenn wir einen Scope mit dem Namen recent, der die kürzlich veröffentlichten und sichtbaren Artikel nach ihrem Veröffentlichungsdatum sortiert zurückgibt, können wir einfach die beiden vorhandenen Scopes wiederverwenden:

scope :recent, visible.published.order("published_at desc")

Hier haben wir also zwei bestehende Scopes in einem neuen zusammengeführt und einen order-Aufruf angehängt. Dieses Verketten von Scopes ist ein sehr praktisches Feature bei der Erzeugung neuer, komplexerer Scopes für unsere Models.

Probieren wir unseren neuen Scope doch einfach in der Konsole aus. Wenn wir Article.recent aufrufen, wird uns ein ActiveRecord::NamedScope::Scope Objekt zurückgegeben. Dieses Objekt verhält sich ganz ähnlich wie das ActiveRecord::Relation Objekt, das wir weiter oben betrachtet haben.

ruby-1.9.1-p378 > Article.recent
 => #<ActiveRecord::NamedScope::Scope:0x0000010318bd08 @table=#<Arel::Table:0x00000102740ea8 
 @name="articles", @options={:engine=>#<Arel::Sql::Engine:0x00000102651900 @ar=ActiveRecord::Base>}, 
 @engine=#<Arel::Sql::Engine:0x00000102651900 @ar=ActiveRecord::Base>>, …

Wenn wir all auf dieses Scope Objekt anwenden, sehen wir die passenden Ergebnisse.

ruby-1.9.1-p378 > Article.recent.all
 => [#<Article id: 1, name: "It's Ancient", published_at: "2010-01-01", 
 hidden: false, created_at: "2010-02-22 20:35:42", updated_at: "2010-02-22 23:00:16">]

Ein letzter Tipp

Beenden wir diese Episode mit einem sehr nützlichen Tipp. Wenn Sie ein Relation oder ein Scope Objekt haben und den SQL-Query sehen wollen, den es ausführen würde, können Sie einfach die Methode to_sql aufrufen:

ruby-1.9.1-p378 > Article.recent.to_sql
 => "SELECT     \"articles\".* FROM       \"articles\" 
 WHERE     (hidden != 't') AND (published_at <= '2010-02-22 22:47:12.023289') 
 ORDER BY  published_at desc"

Diese Methode gibt den SQL-Code zurück, den ActiveRecord ausführen wird, um die zuletzt veröffentlichten und nicht versteckten Artikel von der Datenbank zu erhalten.

Das war's für diese Episode über ActiveRecord Queries in Rails 3! Es gibt jede Menge Neuerungen, die dabei helfen werden, den Code in Ihren Contollern kompakter und klarer zu formulieren. Es lohnt sich also, ein Wenig mit den neuen Features herumzuspielen!

Bundler

Fri, 26 Mar 2010 21:14:42 +0000

In dieser Episode führen wir unsere Vorschau auf die neuen Features von Rails 3 fort. Dieses Mal werfen wir einen Blick auf Bundler, die neue Art, Gem-Abhängigkeiten von Rails-Applikationen zu verwalten.

Bundler wird momentan stetig weiterentwickelt, also geht man am Besten sicher, die aktuellste Version installiert zu haben, indem man

gem install bundler

ausführt. Hierbei bitte beachten, dass nicht sudo eingesetzt wird, da hier eine mit rvm installierte Version von Ruby verwendet wird.

Wie man Bundler benutzt, um Gems zu installieren

In der letzten Episode hatten wir das Problem, dass uns der sqlite3-ruby Gem gefehlt hatte. Wir haben dieses Problem von Hand gelöst, indem wir den Gem per gem install nachinstalliert haben.

gem install sqlite3-ruby

Wir hätten Dies alternativ auch mit Bundler machen können, da in den Abhängigkeiten unserer Applikation sqlite3-ruby aufgeführt ist, also im Gemfile unserer Applikation aufgelistet ist. Um die Abhängigkeiten aufzulösen, führen wir bundle install aus, was alle Einträge durchgeht und sie bei Bedarf nachinstalliert.

$ bundle install
Fetching source index from http://gemcutter.org
Resolving dependencies
Installing abstract (1.0.0) from system gems 
Installing actionmailer (3.0.0.beta) from system gems 
Installing actionpack (3.0.0.beta) from system gems 
Installing activemodel (3.0.0.beta) from system gems 
Installing activerecord (3.0.0.beta) from system gems 
Installing activeresource (3.0.0.beta) from system gems 
Installing activesupport (3.0.0.beta) from system gems 
Installing arel (0.2.1) from rubygems repository at http://gemcutter.org 
Installing builder (2.1.2) from system gems 
Installing bundler (0.9.5) from system gems 
Installing erubis (2.6.5) from system gems 
Installing i18n (0.3.3) from system gems 
Installing mail (2.1.2) from system gems 
Installing memcache-client (1.7.8) from system gems 
Installing mime-types (1.16) from system gems 
Installing rack (1.1.0) from system gems 
Installing rack-mount (0.4.7) from rubygems repository at http://gemcutter.org 
Installing rack-test (0.5.3) from system gems 
Installing rails (3.0.0.beta) from system gems 
Installing railties (3.0.0.beta) from system gems 
Installing rake (0.8.7) from system gems 
Installing sqlite3-ruby (1.2.5) from system gems 
Installing text-format (1.0.0) from system gems 
Installing text-hyphen (1.0.0) from system gems 
Installing thor (0.13.1) from rubygems repository at http://gemcutter.org 
Installing tzinfo (0.3.16) from system gems 
Your bundle is complete!

Anhand der Ausgabe kann man erkennen, dass Bundler alle Gems, die von der Applikation benötigt werden, einschließlich sqlite3-ruby installiert hat. Wäre ein Gem noch nicht installiert gewesen, hätte Bundler ihn von Gemcutter heruntergeladen und nachinstalliert.

Im Zweifelsfall kann man also einfach immer bundle install ausführen, um alle Abhängigkeiten auflösen zu lassen. Immer, wenn man eine neue Applikation erzeugt oder wenn man auf fremden Code zurückgreift, sollte man dieses Kommando laufen lassen, um sicherzugehen, dass man die richtigen Gems installiert hat. Auch beim Ausliefern einer Applikation sollte diese Überprüfung auf dem Produktivsystem stattfinden. Man kann das Kommando auch einfach zu seinen deployment recipes hinzufügen, damit es immer beim Ausliefern automatisch ausgeführt wird.

Es ist jedoch wichtig, zu beachten, dass man niemals sudo verwenden sollte, wenn man bundle install ausführt, auch wenn es sonst man beim Installieren von Gems normalerweise tut.

Gem-Abhängigkeiten in einer Applikation registrieren

Wie fügen wir also solche Abhängigkeiten zu unserer Applikation hinzu? In früheren Rails-Versionen wurden diese in der /config/environment.rb-Datei vermerkt, was sich mit Rails 3 jedoch geändert hat. Die benötigten Gems werden jetzt in einer Gemfile genannten Datei im Rootverzeichnis der Applikation notiert. Das Gemfile einer neuen Rails-Applikation sieht so aus:

# Edit this Gemfile to bundle your application's dependencies.
source 'http://gemcutter.org'


gem "rails", "3.0.0.beta"

## Bundle edge rails:
# gem "rails", :git => "git://github.com/rails/rails.git"

# ActiveRecord requires a database adapter. By default,
# Rails has selected sqlite3.
gem "sqlite3-ruby", :require => "sqlite3"

## Bundle the gems you use:
# gem "bj"
# gem "hpricot", "0.6"
# gem "sqlite3-ruby", :require => "sqlite3"
# gem "aws-s3", :require => "aws/s3"

## Bundle gems used only in certain environments:
# gem "rspec", :group => :test
# group :test do
#   gem "webrat"
# end

Einige Gems sind in dieser Datei schon vermerkt, einschließlich rails und sqlite3-ruby. Besonders beachten sollte man die Versionsnummer in der Zeile, die auf den rails Gem verweist. Zu jeder Referenz in dieser Datei kann man eine bestimmte Version spezifizieren, um eine ganz bestimmte Version eines Gems verwenden zu lassen. Um zu einem bestimmten Zeitpunkt auf eine neue Rails-Version umzusteigen, muss man die Version einfach in dieser Datei vermerken, anstatt wie früher in der environment.rb.

Um zusätzliche Gems in unserer Applikation zu verwenden, muss man sie einfach nur in dieser Datei vermerken. Beispielsweise kann man will_paginate so einbinden:

gem "will_paginate", ">=2.3.12"

Der zweite Parameter gibt an, dass die Version 2.3.12 oder neuer des Gems verwendet werden soll. Sobald dieser Verweis in dem Gemfile steht, kann man den Gem per bundle install automatisch installieren lassen, doch vorher kann man mithilfe von bundle check die Abhängigkeiten prüfen lassen:

$ bundle check
The following dependencies are missing
  * will_paginate (>= 2.3.12, runtime)We can install the missing gems by running bundle install again.

Um eine Auflistung aller verfügbaren Bundle Kommandos zu sehen, gibt man bundle help ein:

$ bundle help
Tasks:
  bundle check        # Checks if the dependencies listed in Gemfile are satisfied by currently installed gems
  bundle exec         # Run the command in context of the bundle
  bundle help [TASK]  # Describe available tasks or one specific task
  bundle init         # Generates a Gemfile into the current working directory
  bundle install      # Install the current environment to the system
  bundle lock         # Locks the bundle to the current set of dependencies, including all child dependencies.
  bundle pack         # Packs all the gems to vendor/cache
  bundle show         # Shows all gems that are part of the bundle.
  bundle unlock       # Unlock the bundle. This allows gem versions to be changed

Andere Möglichkeiten des Gemfiles

Betrachten wir weiterhin das Gemfile und was wir noch damit machen können. Ein sehr nützliches neues Feature ist die Möglichkeit, Gems direkt aus einem git repository zu bekommen. Um beispielsweise immer auf dem aktuellsten Stand der Entwicklung zu sein, kann man den rails Gem auf das zentrale Entwicklungs-repository verweisen lassen:

# Bundle edge rails:
gem "rails", :git => "git://github.com/rails/rails.git"

Dieses Feature eröffnet mächtige neue Möglichkeiten! Wenn ein Gem nicht ganz so funktioniert, wie wir uns vorstellen, können wir das Projekt auf github forken, den Code nach eigenem Ermessen verändern und die Gem-Abhängigkeit auf unser github repository verweisen lassen.

Man kann Gems allerdings auch auf eine bestimmte Umgebung beschränken. Um RSpec für Testzwecke zu laden, kann man Folgendes notieren:

gem "rspec", :group => :test

Wenn man gleich mehrere Gems in einer bestimmten Umgebung laden möchte, kann man group auch einen Block übergeben:

group :test do
  gem "webrat"
  get "rspec"
end

Lässt man bundle install jetzt laufen, werden alle Gems für alle Umgebungen installiert:

$ bundle install
Fetching source index from http://gemcutter.org
Resolving dependencies
...
Installing rspec (1.3.0) from rubygems repository at http://gemcutter.org 
...
Installing webrat (0.7.0) from rubygems repository at http://gemcutter.org 
Installing will_paginate (2.3.12) from system gems 
Your bundle is complete!

Wie man der (verkürzten) Ausgabe entnehmen kann, wurden die Gems aus unserem Gemfile installiert.

Wenn man Gems aus einer bestimmten Umgebung nicht installieren will, verwendet man die Option--without. Um also alle Gems ohne die aus der test-Umgebung zu installieren, führt man Folgendes aus:

bundle install --without=test

Dies ist besonders hilfreich, wenn man seine Applikation auf dem Produktivsystem installieren will, ohne die ganzen Gems, die fürs Testen benötigt werden, mitzuinstallieren.

Gems sperren

Ein weiteres sehr nützliches Kommando ist bundle lock. Es sperrt die exakten Versionen der Gems, die unsere Applikation nutzt. Nachdem dieses Kommando ausgeführt wurde, existiert eine neue Datei mit dem Namen Gemfile.lock. Diese Datei listet alle Gems zusammen mit ihrer jeweiligen Version auf, die für unsere Applikation installiert wurden. Nach der Ausführung von bundle lock werden durch bundle install nur noch genau die Gems in den Versionen installiert, die im Gemfile.lock vermerkt sind, selbst wenn neuere Versionen verfügbar sein sollten.

Wenn man mit anderen Rails-Entwicklern zusammen an einem Projekt arbeitet, kann man bundle lock verwenden, um sicherzugehen, dass Jeder die gleichen Versionen aller benötigten Gems verwendet. Das Gleiche gilt beim Deployment einer Applikation auf das Produktivsystem. Falls eine Applikation auf einen anderen Server umziehen muss, will man sichergehen, dass exakt die gleichen Voraussetzungen vorherrschen wie auf unserem Entwicklungssystem.

Muss man zu einem späteren Zeitpunkt Änderungen an den Abhängigkeiten vornehmen, sollte man allerdings nicht einfach das Gemfile.lock verändern. Stattdessen bringt man das Gemfile auf den gewünschten Stand und führt das bundle install-Kommando mit der zusätzlichen Option --relock aus:

bundle install --relock

Dadurch werden die Gems entsperrt, auf die gewünschte Version gebracht und wieder gesperrt.

Gems in der Applikation installieren

Das letzte zu betrachtende Feature ist bundle pack. Normalerweise installiert Bundler alle Gems im .bundle-Verzeichnis im Hauptverzeichnis des aktuellen Benutzers:

$ ls ~/.bundle
cache		doc		gems		ruby		specifications

Daraus folgt natürlich, dass die Gems nicht im Verzeichnis der jeweiligen Applikation liegen und damit auch nicht im verwendeten Versionskontrollsystem landen. Möchten wir allerdings die Gems mit unserer Anwendung ausliefern, können wir bundle pack verwenden:

bundle pack
Copying .gem files into vendor/cache
  * memcache-client-1.7.8.gem
  * rspec-1.3.0.gem
  * thor-0.13.3.gem
  * tzinfo-0.3.16.gem
  * builder-2.1.2.gem
  * nokogiri-1.4.1.gem
  * mime-types-1.16.gem
  * sqlite3-ruby-1.2.5.gem
  * i18n-0.3.3.gem
  * abstract-1.0.0.gem
  * erubis-2.6.5.gem
  * text-hyphen-1.0.0.gem
  * bundler-0.9.6.gem
  * rake-0.8.7.gem
  * will_paginate-2.3.12.gem
  * text-format-1.0.0.gem
  * rack-1.1.0.gem
  * rack-test-0.5.3.gem
  * webrat-0.7.0.gem
  * rack-mount-0.4.7.gem
  * activesupport-3.0.0.beta.gem
  * mail-2.1.2.gem
  * arel-0.2.1.gem
  * activemodel-3.0.0.beta.gem
  * actionpack-3.0.0.beta.gem
  * actionmailer-3.0.0.beta.gem
  * activerecord-3.0.0.beta.gem
  * activeresource-3.0.0.beta.gem
  * railties-3.0.0.beta.gem
  * rails-3.0.0.beta.gem

Damit werden die .gem-Dateien, die unsere Applikation verwendet, ins Verzeichnis /vendor/cache der Applikation kopiert (wobei das Verzeichnis bei Bedarf erzeugt wird, wenn es noch nicht existiert). Alle so gespeicherten Gems werden danach aus diesen .gem-Dateien installiert, anstatt sie beispielsweise von Gemcutter zu laden. Normalerweise sollte man dieses Feature nicht all zu oft benötigen, doch wenn man in die Situation kommt, dass das Produktivsystem keine Möglichkeit hat, Gems von Gemcuttoer oder anderen Quellen herunterzuladen, leistet einem bundle pack gute Dienste.

Damit beenden wir die aktuelle Episode. Wir hoffen, sie hat Ihnen einen guten Überblick vermittelt, wie man Bundler einsetzen kann, um Gems und Abhängigkeiten zu verwalten. Nach einer kurzen Einarbeitungszeit kann Bundler die Probleme, die oft mit diesen Abhängigkeiten bestanden haben, endgültig zur Vergangenheit gehören lassen.

Zu guter letzt möchten wir Sie noch auf railsplugins.org hinweisen, falls Sie sich gefragt haben, welche Gems und Plugins mit Rails 3 funktionieren. Auf dieser Seite können Sie Plugins und Gems durchsuchen, ob sie mit Rails 3 und Ruby 1.9 funktionieren.

Falls ein Gem als "not working" aufgelistet ist, ist dies eine grossartige Möglichkeit, einfach mitzuarbeiten! Auf diese Weise können Sie mithelfen, so viele Gems und Plugins wie möglich für Rails 3 zu portieren.

Rails 3 Beta and RVM

Mon, 01 Mar 2010 22:56:26 +0000

Gibt es bessere Wege die 200. Episode zu feiern als einen ersten Eindruck von Rails 3 zu vermitteln? Die erste Betaversion von Rails 3.0 ist gerade veröffentlicht worden und in dieser Episode zeigen wir die Installation und Konfiguration. In den nächsten Episoden werden wir einen detaillierten Blick auf neue Funktionen werfen. Auch wenn gar keine Upgrades der Applikationen in naher Zukunft geplant sind, mit den neuen Funktionen herumzuprobieren ist die Installation der Betaversion wert.

Ruby aktualisieren

Rails 3 braucht Ruby 1.8.7 oder neuer, als ersten Schritt schaue nach welche Version du gerade verwendest indem du ruby -v in einem Terminalfenster eingibst.

$ ruby -v
ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]

Dieser Computer verwendet Ruby 1.8.6, wir müssen auf eine neuere Version aktualisieren bevor wir weiter machen können. Wir werden rvm verwenden, den Ruby Version Manager. Mit rvm können wir auf einfache Weise verschiedene Versionen von Ruby verwenden und mit einem einzelnenen Kommando zwischen ihnen hin- und herschalten.

Solltest du Windows benutzen, dann musst du ruby manuell installieren, rvm ist dort nicht verfügbar. Unter Linux, OS X und anderen UNIX-basierenden Systemen können wir rvm mit den Anweisungen auf der rvm Installationsseite (engl) einrichten und dann folgendes Kommando absetzen:

mkdir -p ~/.rvm/src/ && cd ~/.rvm/src && rm -rf ./rvm/ && git clone git://github.com/wayneeseguin/rvm.git && cd rvm && ./install

Nachdem die Kommandos ausgeführt wurden, werden Instruktionen angezeigt wie man die Installation abschliesst. Je nachdem, ob du bash oder zsh verwendest, gibt es verschiedene Hinweise. Nachdem wir die Instruktionen befolgt haben, müssen wir unser Terminalfenster schliessen und neu aufmachen, damit die Änderungen aktiv werden. Jetzt können wir rvm ausführen und die Ruby Version installieren, die wir wollen.

Rails 3.0 benötigt Ruby 1.8.7, läuft aber auch mit Ruby 1.9.1. Wir sind abenteuerlustig und werden 1.9.1 installieren. Dazu geben wir folgendes ein:

$ rvm install 1.9.1

Dieser Befehl lädt die Version aus dem Netz, konfiguriert und installiert Ruby 1.9.1. Dieser Prozess dauert einige Zeit. Nach Abschluss können wir mit rvm list feststellen, welche Ruby Versionen wir installiert haben.

noonoo:~ eifion$ rvm list
   ruby-1.9.1-p378 [ x86_64 ]
   system [ x86_64 i386 ppc ]

Wir haben Ruby 1.9.1 installiert und können mit folgendem Befehl darauf umschalten.

$ rvm 1.9.1
$ ruby -v
ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-darwin10.2.0]

Die neue Ruby Version bleibt nur solange aktiv bis das Terminalfenster geschlossen wird. Um die neu installierte Version dauerhaft aktiv zu machen können wir den Parameter --default zu rvm dazuschreiben.

$ rvm 1.9.1 --default
$ ruby -v
ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-darwin10.2.0]

Jetzt können wir beliebig viele Terminalfenster auf- und wieder zumachen, Ruby 1.9.1 bleibt aktiv.

Falls wir irgendwann wieder zu der Ruby Version des Systems retour wollen, dann können wir rvm system absetzen, mit dem Parameter --default wird auch diese Änderung dauerhaft aktiviert.

Installation von Rails Beta

Jetzt haben wir eine Ruby Version mit der wir Rails 3 Beta verwenden können. Wir setzen die folgenden 2 Zeilen ab um Rails zu installieren.

gem install tzinfo builder memcache-client rack rack-test rack-mount erubis mail text-format thor bundler i18n
gem install rails --pre

Weil wir eine noch nicht veröffentlichte Version von Rails verwenden wollen müssen wir die Abhöngigkeiten selbst installieren, die erste Zeile erledigt das. Bitte beachte dass wir kein sudo vor den Befehl gem setzen. Der Grund dafür ist die Verwendung von rvm. Die Seite rvm gems page gibt dazu weitere Informationen.

Nachdem beide Kommandos ausgeführt wurden haben wir Rails 3.0 installiert und können beginnen es auszuprobieren.

Rails 3.0 benutzen

Zuerst überprüfen wir ob Rails 3 wirklich installiert wurde mit rails -v.

$ rails -v
Rails 3.0.0.beta

Wenn du eine Fehlermeldung siehst dann schließe dein Terminalfenster und mache es neu auf und probiere es erneut. Wir werden nun eine einfache Applikation bauen die Spielstände abspeichert, wir nennen sie topscore. Wir erstellen eine Rails 3.0 Applikation auf die gleiche Weise wie bisher:

rails topscore

Aber wenn wir in das Applikationsverzeichnis wechseln und versuchen den Server zu starten bemerken wir den ersten Unterschied.

¸
$ script/server
-bash: script/server: No such file or directory

In dem Verzeichnis script gibt es keine der bisher benutzten Skripte mehr, wie starten wir den Server? Wir benutzen rails mit dem folgenden Parameter:

rails server

Die nach dem Ausführen des Kommandos angezeigten Fehlermeldungen nehmen wir in Kauf, wir arbeiten mit einer Beta-Release. In den Fehlermeldungen kann man ein fehlendes gem sqlite3-ruby erkennen. Hier bitte beachten dass jede Ruby Version eigene Pakete von RubyGems verwendet. Deshalb müssen wir das sqlite3-ruby gem selbst installieren, auch hier wieder ohne sudo.

gem install sqlite3-ruby

Nach einem Start des Servers mit rails server sehen wir eine Menge an Ausgaben und Warnings, aber der Server startet. Auf der Seite http://localhost:3000 sehen wir die Rails Default Seite.

Jetzt können wir anfangen unsere Applikation zu entwickeln. Wir starten mit einem Scaffold für ein Spiel-Model game mit einem Attribut name vom Typ string.

rails generate scaffold game name:string

Wir lassen uns von den vielen Meldungen nicht abhalten und werden als nächstes die Datenbank migrieren.

rake db:migrate

Mit einem Browser auf die Applikationssseite zugegriffen, sehen wir die üblichen per Scaffold generierten Seiten, die du eventuell aus anderen Applikationen kennst.

Das war es mit unserer Applikation für heute, in späteren Episoden werden wir auf neue Funktionen von Rails 3 detaillierter eingehen, in der Zwischenzeit kannst du hier Rails 3.0 Release Notes einen Überblick über die Änderungen bekommen. Es gibt auch eine grosse Sammlung von Links über Rails 3 bei Ruby Inside.

Beim Arbeiten mit Beta-Software kann es vorkommen, dass Dinge nicht funktionieren und man Fehler und Probleme entdeckt. Falls dir das passiert, und du weißt, dass es nichts mit deinem einen Programmcode zu tun hat, dann überprüfe als allererstes die verwendeten Gems oder Plugins, die deine Applikation verwendet. Die Chancen sind hoch, dass dort das Problem liegt weil das Gem/Plugin (noch) nicht mit Rails 3 oder Ruby 1.9 zusammenarbeitet. Falls du ein Problem einem bestimmten Gem/Plugin zuordnen kannst, dann erstelle bitte ein Ticket auf der Gem Projektseite, damit der Fehler behoben werden kann.

Falls das Problem bei Rails selbst liegt kannst du beim Rails Lighthouse ein Ticket erstellen. Falls du einen Fehler meldest, beachte bitte die folgenden Tipps: Such in bestehenden Tickets, ob das Problem nicht bereits existent ist. Erstelle eine Anleitung zum reproduzieren des Fehlers, füge deine Fehlermeldungen und einen stack trace hinzu. Bitte notiere auch die Version von Ruby on Rails, die du zusammen mit den eingebundenen Gems verwendest, damit es leichter wird, das Problem nachzuvollziehen. Gut beschriebene Fehler in Tickets erleichtern die Behebung des Problems.

Gib etwas an Freie Software zurück

Wie du vielleicht schon bemerkt hast ist dies die 200. Episode. Um den 200. Screencast hervorzuheben startet Ryan Bates eine Kampagne namens “Give Back To Open Source”. Open Source Software entsteht durch viel Arbeit und ist frei erhältlich, somit macht es Sinn für jedermann, sich daran zu beteiligen und etwas zurück zu geben. Ryan’s Herausforderung an Dich ist es, Deine grösste Rails Applikation zu öffnen und die verschiedenen Plug-ins und Gems zu getrachten, die es benutzt. Viele Gems Projektseiten akzeptieren Spenden, und jeder auch noch so kleine Beitrag wird sehr geschätzt, da er dabei hilft, die Entwicklung des Gems am Laufen zu halten.

Eine andere Möglichkeit ist es, sich die Liste der Probleme für das Projekt anzusehen, sich damit zu beschäftigen, einen Bug zu beheben oder bei der Dokumentation zu helfen. Es liegt an Dir, Dich für eine Möglichkeit zu entscheiden, um beizutragen, aber es ist sehr erwünscht, da es der Rails Community hilft, voranzukommen.

ASCIIcasts - Full Episode Feed

Controller in Rails 3

Parameter Logging

Redirect-Kurzformen

Permanente Cookies

respond_with benutzen

Unobtrusive JavaScript

Wie Rails 3 data-Attribute verwendet

Hinzufügen von AJAX-Funktionalität zum Suchfeld

Auswechseln des Frameworks

Stilles Zurückfallen auf nicht-JavaScript-Funktionalität

Active Record Queries in Rails 3

Ein paar einfache Beispiele

Lazy Loading

Named Scopes

Ein letzter Tipp

Bundler

Wie man Bundler benutzt, um Gems zu installieren

Gem-Abhängigkeiten in einer Applikation registrieren

Andere Möglichkeiten des Gemfiles

Gems sperren

Gems in der Applikation installieren

Rails 3 Beta and RVM

Ruby aktualisieren

Installation von Rails Beta

Rails 3.0 benutzen

Gib etwas an Freie Software zurück

`respond_with` benutzen

Wie Rails 3 `data`-Attribute verwendet