Um Elemente eines HTML Dokuments zu Adressieren, z.B. fuer Event Handler in JavaScript, oder fuer Tests der Benutzerschnittstelle mit Capybara oder Selenium verwendet man ueblicherweise entweder das ID Attribut, oder das Class Attribut.

Beide haben Nachteile, bzw. sind nicht optimal. Ein ID Attribut kann man pro Seite nur ein Mal verwenden. Das Class Attribut ist eigentlich dazu gedacht das Aussehen eines Elements festzulegen und nicht den Zweck anzuzeigen. Dies fuehrt dann dazu das man eine Menge Klassen hat, zu der man keine entsprechende Definition in der CSS Datei findet.

In dem Artikel „Write better cukes with the rel attribute“ schlaegt Steve Klabnik nun vor, dieses Attribut statt dem Class Attribut zu verwenden um Links eine Bedeutung zuzuweisen.

Eigentlich ist es erstaunlich das das Rel Attribut in dieser Hinsicht nicht haeufiger verwendet wird. Denn das Attribut exisitiert seit HTML 1 und ist uns allen vom Link Element gelaeufig. Dort wird es mit dem Wert „stylesheet“ verwendet um CSS-Dateien einzubinden.

Ein Grund fuer die geringe Verwendung mag der sperrige Selektor sein. Der sieht naemlich beispielsweise in jQuery so aus: $(‘a[rel="edit-article"]‘), bei einer Klasse wuerde $(‘.edit-article’) ausreichen.
Ein weiterer Grund ist sicher, dass der Link durch das Rel Attribut, allgemein verstaendlich sein sollte. So das auch die Suchmaschienen, den Link interpretieren koennen und nicht nur der Web Developer, der die Seite erstellt hat. Daher gibt es inzwischen eine recht lange Liste mit registrierten Link Typen.

Kurz bevor ich aufgeben und auf eine andere Templating Loesung zurueckgreifen wollte, habe ich doch noch ein sehr ausfuehrliches Tutorial fuer eine Anwendung in Sproutcore 1 und 2 gefunden, die eine Tabelle enthaelt.

Durch die Aufteilung der Table-Tags in den HTML Code und die Handlebar-Elemente finde ich es schwierig das “intuitiv” hinzubekommen.

Lange Rede, kurzer Sinn. So bekommt man in Sproutcore 2 eine Tabelle hin:

Wenn man sich im Web mit JavaScript beschäftigt, begegnet man zur Zeit ständig CoffeeScript. Das führt zwangsläufig dazu, daß man sich CoffeeScript ein mal anschaut und es ausprobieren moöchte. Bevor man gleich mit CoffeeScript beginnt und es sich installiert, kann man es Online interaktiv testen. Auf der CoffeeScript Site gibt es die Möglichkeit CoffeeScript in JavaScript umzuwandeln (dazu im Menü auf “TRY COFFEESCRIPT” klicken), dabei sieht man beim Tippen im linken Fenster, den entsprechenden JavaScript Code im rechten Fenster.
Das Ganze gibt es dann auch andersherum, allerdings auf einer anderen Site (js2coffee). Dort gibt man JavaScript ein und es entsteht CoffeeScript.
Wenn man jetzt beides zusammen nimmt bekommt man die Moöglichkeit Online JavaScript in CoffeeScript und wieder zurück in JavaScript umzuwandeln. Wozu soll das jetzt gut sein? Man kann nun die Vorteile von CoffeeScript verwenden, ohne das man direkt CoffeeScript einsetzt.
Laut der CoffeeScript Site ist der von CoffeeScript generierte Code mindestens gleich schnell wie handgeschriebenes JavaScript und das ist auch plausibel, wenn man bedenkt wie flexibel JavaScript ist.

Günstig zur Klasse

Wenn man mit älterem JavaScript Code arbeitet findet man häufig prozeduralen Code, also Code der nur aus Funktionen besteht. Alle Funktionen sind öffentlich, man hat globale Variablen. Mit der Umwandlung zu CoffeeScript und wieder zurück kann man diese Funktionen schnell zu Klassen, genauer gesagt klassenartigen Objekten, zusammenfassen und den Code so an den “Stand der Technik” anpassen.
Man muss nur ein „class <Klassenname>“ den Funktionen voranstellen und am Ende die öffentlichen Funktionen definieren. Man spart sich damit einiges an Tipparbeit und sieht auch gleich wie man in JavaScript Klassen erstellt, falls man es vorher noch nicht wusste.
Im linken Beispiel sieht man am Anfang eine Funktion namens “a”. Im Schritt zwei wurde der JavaScript Code mit js2coffee nach CoffeeScript umgewandelt. Es wurde eine Klasse erstellt mit “class Klasse”. Die Funktion wurden eingerückt, damit sie der Klasse zugeordnet ist. Am Ende der Klasse wird die Funktion “a” mit der Zuweisung: this.a = a als öffentlich deklariert. Die Klasse ist damit vollständig und wurde im letzten Schritt wieder in JavaScript umgewandelt.

Codequalität

Wie schon angesprochen ist JavaScript recht flexibel. Es macht nicht unbedingt etwas, wenn man ein Semikolon am Ende vergisst, die meisten kennen den Unterschied zwischen == und === nicht, oder das “Hoisting” der Variablendeklarationen. Diese Ungenauigkeiten in JavaScript können zu subtilen Fehlern führen, daher ist es ratsam den Code mit einem Syntaxchecker wie JSLint zu prüfen.
Diese Arbeit nimmt einem CoffeeScript ab, denn CoffeeScript generiert gleich JSLint konformen Code.

require 'sass/plugin/rack'
use Sass::Plugin::Rack
Sass::Plugin.options = Compass.sass_engine_options

Dann werden bei einer Anfrage die Dateien aus public/stylesheets/sass nach public/stylesheets übersetzt.

Im Sinatra Controller benötigt man dann natürlich noch folgende Funktion für die CSS Dateien:

get "/stylesheets/:name.css" do
   content_type 'text/css'
   File.read(File.join('public/stylesheets', "#{params[:name]}.css"))
end

Den kompletten Code gibt es auf Github.

In the simplest terms, “git pull” does a “git fetch” followed by a “git merge”.

Ich musste also ein git merge ausführen. Die nächste Klippe: Wie heisst der zu mergende Branch? Ich probierte “git merge git-svn” und das klappte dann tatsächlich. Nach dem Ausführen hatte ich den master Branch und der Checkout Prozess war endlich abgeschlossen.

Compass und SASS

Damit das richtige CSS generiert wird fügt muß das compass Gem hinzugefügt werden. Bisher ist dafür noch eine spezielle Version für Rails 3.1 nötig.

gem 'compass', :git => 'https://github.com/chriseppstein/compass.git',:branch => 'rails31'

Nun bindet man noch ein sass-rails Gem ein:

gem 'sass-rails', :git => 'https://github.com/rails/sass-rails.git'

Update: Inzwischen ist es nicht mehr nötig die Git repositories anzugeben. Ein “gem ‘compass’” und “gem ‘sass’” reichen aus.

Die Compass Stylesheets müssen noch dem Sass Ladepfad hinzuzufügt werden.
Für sass-rails macht man dies in config/application.rb:

config.sass.load_paths ||= []
config.sass.load_paths << "#{Gem.loaded_specs['compass'].full_gem_path}/frameworks/compass/stylesheets"

Im Rails Wurzelverzeichnis gibt man nun:

compass init rails .

ein, was die Datei config/compass.rb erzeugt.

Sproutcore.js einbinden

Für Sproutcore gibt es das Gem sproutcore-rails, das ähnlich wie jquery-rails, Sproutcore.js in einem Gem zur Verfügung stellt.
Es wird dann nur ein

//= require sproutcore

in app/assets/javascripts/application.js benötigt.
Möchte man den Javascript Code jedoch noch testen sollte man sich sproutcore.js seperat in das assets/javascripts Verzeichnis kopieren.
Nun ist Sproutcore in die Rails Anwendung integriert und man kann beginnen Sproutcore zu verwenden.

Jasmine

Zum Testen der Sproutcore Anwendung habe ich Jasmine verwendet, das in der Railscasts Folge 261 vorgestellt wurde. Damit Jasmine mit Rails 3.1 funktioniert, müssen lediglich die JavaScript-Dateien in spec/javascripts/support/jasmine.yml angegeben werden.

src_files:
- app/assets/javascripts/sproutcore-2.0.a.3.js
- app/assets/javascripts/todos.js

Nun kann man mit den Tests beginnen:

describe("Todos", function() {
  it("should add a todo element", function(){
    var todosController=Todos.todosController;
    todosController.createTodo("new Todo");
    expect(todosController.content.objectAt(0).title).toEqual("new Todo");
  });
});