sinatra 1.3.6 → 1.4.0.a

data/CHANGES

@@ -1,12 +1,101 @@
-= 1.3.6 (backport release) / 2013-03-15
+= 1.4.0 / Not Yet Released
 
-Backported from 1.4.0:
+ * Add support for Yajl templates. (Jamie Hodge)
 
- * Take views option into account for template caching. (Konstantin Haase)
+ * Add support for Rabl templates. (Jesse Cooke)
 
- * Improve documentation (Konstantin Haase)
+ * Add support for Wlang templates. (Bernard Lambeau)
 
- * No longer override `define_singleton_method`. (Konstantin Haase)
+ * You can now pass a block to ERb, Haml, Slim, Liquid and Wlang templates,
+   which will be used when calling `yield` in the template. (Alexey Muranov)
+
+ * When running in classic mode, no longer include Sinatra::Delegator in Object,
+   instead extend the main object only. (Konstantin Haase)
+
+ * Improved route parsing: "/:name.?:format?" with "/foo.png" now matches to
+   {name: "foo", format: "png"} instead of {name: "foo.png"}. (Florian Hanke)
+
+ * Add :status option support to send_file. (Konstantin Haase)
+
+ * The `provides` condition now respects an earlier set content type.
+   (Konstantin Haase)
+
+ * Exception#code is only used when :use_code is enabled. Moreover, it will
+   be ignored if the value is not between 400 and 599. You should use
+   Exception#http_status instead. (Konstantin Haase)
+
+ * Status, headers and body will be set correctly in an after filter when using
+   halt in a before filter or route. (Konstantin Haase)
+
+ * Sinatra::Base.new now returns a Sinatra::Wrapper instance, exposing
+   #settings and #helpers, yet going through the middleware stack on #call.
+   It also implements a nice #inspect, so it plays nice with Rails' `rake
+   routes`. (Konstantin Haase)
+
+ * In addition to WebRick, Thin and Mongrel, Sinatra will now automatically pick
+   up Puma, Trinidad, ControlTower or Net::HTTP::Server when installed. The
+   logic for picking the server has been improved and now depends on the Ruby
+   implementation used. (Mark Rada, Konstantin Haase)
+
+ * "Sinatra doesn't know this ditty" pages now show the app class when running
+   a modular application. This helps detecting where the response came from when
+   combining multiple modular apps. (Konstantin Haase)
+
+ * When port is not set explicitly, use $PORT env variable if set and only
+   default to 4567 if not. Plays nice with foreman. (Konstantin Haase)
+
+ * Allow setting layout on a per engine basis. (Zachary Scott, Konstantin Haase)
+
+ * You can now use `register` directly in a classic app. (Konstantin Haase)
+
+ * `redirect` now accepts URI or Addressable::URI instances. (Nicolas
+   Sanguinetti)
+
+ * Have Content-Disposition header also include file name for `inline`, not
+   just for `attachment`. (Konstantin Haase)
+
+ * Better compatibility to Rack 1.5. (James Tucker, Konstantin Haase)
+
+ * Make route parsing regex more robust. (Zoltan Dezso, Konstantin Haase)
+
+ * Improve Accept header parsing, expose parameters. (Pieter van de Bruggen)
+
+ * Add `layout_options` render option. Allows you, amongst other things, to
+   render a layout from a different folder. (Konstantin Haase)
+
+ * Explicitly setting `layout` to `nil` is treated like setting it to `false`.
+   (richo)
+
+ * Properly escape attributes in Content-Type header. (Pieter van de Bruggen)
+
+ * Default to only serving localhost in development mode. (Postmodern)
+
+ * Setting status code to 404 in error handler no longer triggers not_found
+   handler. (Konstantin Haase)
+
+ * The `protection` option now takes a `session` key for force
+   disabling/enabling session based protections. (Konstantin Haase)
+
+ * Add `x_cascade` option to disable `X-Cascade` header on missing route.
+   (Konstantin Haase)
+
+ * Improve documentation. (Kashyap, Stanislav Chistenko, Zachary Scott, 
+   Anthony Accomazzo, Peter Suschlik, Rachel Mehl, ymmtmsys, Anurag Priyam,
+   burningTyger, Tony Miller, akicho8, Vasily Polovnyov, Markus Prinz,
+   Alexey Muranov, Konstantin Haase)
+
+ * Convert documentation to Markdown. (Kashyap, Robin Dupret, burningTyger,
+   Vasily Polovnyov)
+
+ * Don't set not_found content type to HTML in development mode with custom
+   not_found handler. (Konstantin Haase)
+
+ * Fix mixed indentation for private methods. (Robin Dupret)
+
+ * Recalculate Content-Length even if hard coded if body is reset. Relevant
+   mostly for error handlers. (Nathan Esquenazi, Konstantin Haase)
+
+ * Take views option into account for template caching. (Konstantin Haase)
 
 = 1.3.5 / 2013-02-25
 
@@ -14,6 +103,8 @@ Backported from 1.4.0:
 
  * Improve documentation (Konstantin Haase)
 
+ * No longer override `define_singleton_method`. (Konstantin Haase)
+
 = 1.3.4 / 2013-01-26
 
  * Improve documentation. (Kashyap, Stanislav Chistenko, Konstantin Haase,
@@ -58,9 +149,6 @@ Backported from 1.4.0:
  * When protecting against CSRF attacks, drop the session instead of refusing
    the request. (Konstantin Haase)
 
- * Status, headers and body will be set correctly in an after filter when using
-   halt in a before filter or route. (Konstantin Haase)
-
 = 1.3.2 / 2011-12-30
 
  * Don't automatically add `Rack::CommonLogger` if `Rack::Server` is adding it,
@@ -223,20 +311,6 @@ Backported from 1.4.0:
  * Fix handling of broken query params when displaying exceptions. (Luke
    Jahnke)
 
-= 1.2.9 (backports release) / 2013-03-15
-
-IMPORTANT: THIS IS THE LAST 1.2.x RELEASE, PLEASE UPGRADE.
-
- * Display EOL warning when loading Sinatra. (Konstantin Haase)
-
- * Improve documentation. (Anurag Priyam, Konstantin Haase)
-
- * Do not modify the load path. (Konstantin Haase)
-
- * Display deprecation warning if RUBY_IGNORE_CALLERS is used. (Konstantin Haase)
-
- * Add backports library so we can still run on Ruby 1.8.6. (Konstantin Haase)
-
 = 1.2.8 (backports release) / 2011-12-30
 
 Backported from 1.3.2:

data/Gemfile

@@ -7,7 +7,7 @@
 # If you have issues with a gem: `bundle install --without-coffee-script`.
 
 RUBY_ENGINE = 'ruby' unless defined? RUBY_ENGINE
-source 'https://rubygems.org/' unless ENV['QUICK']
+source :rubygems unless ENV['QUICK']
 gemspec
 
 gem 'rake'
@@ -32,20 +32,23 @@ gem 'haml', '>= 3.0'
 gem 'sass' if RUBY_VERSION < "2.0"
 gem 'builder'
 gem 'erubis'
-gem 'liquid' unless RUBY_ENGINE == 'rbx' and RUBY_VERSION > '1.9'
 gem 'slim', '~> 1.0'
 gem 'temple', '!= 0.3.3'
 gem 'coffee-script', '>= 2.0'
-gem 'rdoc', RUBY_VERSION < '1.9' ? '~> 3.12' : '>= 4.0'
+gem 'rdoc', '~> 3.12'
 gem 'kramdown'
 gem 'maruku'
 gem 'creole'
 gem 'markaby'
 gem 'radius'
+gem 'rabl' unless RUBY_ENGINE =~ /jruby|maglev/
+gem 'wlang', '>= 2.0.1' unless RUBY_ENGINE =~ /jruby|rbx/
+gem 'liquid' unless RUBY_ENGINE == 'rbx' and RUBY_VERSION > '1.9'
 
 if RUBY_ENGINE == 'jruby'
   gem 'nokogiri', '!= 1.5.0'
   gem 'jruby-openssl'
+  gem 'trinidad'
 else
   gem 'yajl-ruby'
   gem 'nokogiri'
@@ -54,6 +57,8 @@ end
 
 if RUBY_ENGINE == "ruby" and RUBY_VERSION > '1.9'
   gem 'less', '~> 2.0'
+else
+  gem 'less', '~> 1.0'
 end
 
 if RUBY_ENGINE != 'jruby' or not ENV['TRAVIS']
@@ -64,11 +69,14 @@ if RUBY_ENGINE != 'jruby' or not ENV['TRAVIS']
     gem 'mongrel'
   end
   gem 'RedCloth' unless RUBY_ENGINE == "macruby"
+  gem 'puma'
 
   ## bluecloth is broken
   #gem 'bluecloth'
 end
 
+gem 'net-http-server'
+
 platforms :ruby_18, :jruby do
   gem 'json' unless RUBY_VERSION > '1.9' # is there a jruby but 1.8 only selector?
 end

data/README.de.md

@@ -0,0 +1,2590 @@
+# Sinatra
+
+*Wichtig: Dieses Dokument ist eine Übersetzung aus dem Englischen und unter
+Umständen nicht auf dem aktuellen Stand.*
+
+Sinatra ist eine
+[DSL](http://de.wikipedia.org/wiki/Domänenspezifische_Sprache), die das
+schnelle Erstellen von Webanwendungen in Ruby mit minimalem Aufwand
+ermöglicht:
+
+```ruby
+    # myapp.rb
+    require 'sinatra'
+    get '/' do
+      'Hallo Welt!'
+    end
+```
+
+Einfach via `rubygems` installieren und starten:
+
+```ruby
+    gem install sinatra
+    ruby myapp.rb
+```
+
+Die Seite kann nun unter http://localhost:4567 betrachtet werden.
+
+Es wird empfohlen, den Thin-Server via `gem install thin` zu installieren, den
+Sinatra dann, soweit vorhanden, automatisch verwendet.
+
+## Routen
+
+In Sinatra wird eine Route durch eine HTTP-Methode und ein URL-Muster definiert.
+Jeder dieser Routen wird ein Ruby-Block zugeordnet:
+
+```ruby
+    get '/' do
+      .. zeige etwas ..
+    end
+
+    post '/' do
+      .. erstelle etwas ..
+    end
+
+    put '/' do
+      .. update etwas ..
+    end
+
+    delete '/' do
+      .. entferne etwas ..
+    end
+
+    options '/' do
+      .. zeige, was wir können ..
+    end
+```
+
+Die Routen werden in der Reihenfolge durchlaufen, in der sie definiert wurden.
+Das erste Routen-Muster, das mit dem Request übereinstimmt, wird ausgeführt.
+
+Die Muster der Routen können benannte Parameter beinhalten, die über den
+`params`-Hash zugänglich gemacht werden:
+
+```ruby
+    get '/hallo/:name' do
+      # passt auf "GET /hallo/foo" und "GET /hallo/bar"
+      # params[:name] ist 'foo' oder 'bar'
+      "Hallo #{params[:name]}!"
+    end
+```
+
+Man kann auf diese auch mit Block-Parametern zugreifen:
+
+```ruby
+    get '/hallo/:name' do |n|
+      "Hallo #{n}!"
+    end
+```
+
+Routen-Muster können auch mit Splat- oder Wildcard-Parametern über das
+`params[:splat]`-Array angesprochen werden:
+
+```ruby
+    get '/sag/*/zu/*' do
+      # passt auf /sag/hallo/zu/welt
+      params[:splat] # => ["hallo", "welt"]
+    end
+
+    get '/download/*.*' do
+      # passt auf /download/pfad/zu/datei.xml
+      params[:splat] # => ["pfad/zu/datei", "xml"]
+    end
+```
+
+Oder mit Block-Parametern:
+
+```ruby
+    get '/download/*.*' do |pfad, endung|
+      [pfad, endung] # => ["Pfad/zu/Datei", "xml"]
+    end
+```
+
+Routen mit regulären Ausdrücken sind auch möglich:
+
+```ruby
+    get %r{/hallo/([\w]+)} do
+      "Hallo, #{params[:captures].first}!"
+    end
+
+Und auch hier können Block-Parameter genutzt werden:
+
+```ruby
+    get %r{/hallo/([\w]+)} do |c|
+      "Hallo, #{c}!"
+    end
+```
+
+Routen-Muster können auch mit optionalen Parametern ausgestattet werden:
+
+```ruby
+    get '/posts.?:format?' do
+      # passt auf "GET /posts" sowie jegliche Erweiterung
+      # wie "GET /posts.json", "GET /posts.xml" etc.
+    end
+```
+
+Anmerkung: Solange man den sog. Path Traversal Attack-Schutz nicht deaktiviert
+(siehe weiter unten), kann es sein, dass der Request-Pfad noch vor dem
+Abgleich mit den Routen modifiziert wird.
+
+### Bedingungen
+
+An Routen können eine Vielzahl von Bedingungen angehängt werden, die erfüllt
+sein müssen, damit der Block ausgeführt wird. Möglich wäre etwa eine
+Einschränkung des User-Agents:
+
+```ruby
+    get '/foo', :agent => /Songbird (\d\.\d)[\d\/]*?/ do
+      "Du verwendest Songbird Version #{params[:agent][0]}"
+    end
+
+    get '/foo' do
+      # passt auf andere Browser
+    end
+```
+
+Andere mitgelieferte Bedingungen sind `host_name` und `provides`:
+
+```ruby
+    get '/', :host_name => /^admin\./ do
+      "Adminbereich, Zugriff verweigert!"
+    end
+
+    get '/', :provides => 'html' do
+      haml :index
+    end
+
+    get '/', :provides => ['rss', 'atom', 'xml'] do
+      builder :feed
+    end
+```
+
+Es können auch andere Bedingungen relativ einfach hinzugefügt werden:
+
+```ruby
+    set(:probability) { |value| condition { rand <= value } }
+
+    get '/auto_gewinnen', :probability => 0.1 do
+      "Du hast gewonnen!"
+    end
+
+    get '/auto_gewinnen' do
+      "Tut mir leid, verloren."
+    end
+```
+
+Bei Bedingungen, die mehrere Werte annehmen können, sollte ein Splat verwendet
+werden:
+
+```ruby
+    set(:auth) do |*roles|   # <- hier kommt der Splat ins Spiel
+      condition do
+        unless logged_in? && roles.any? {|role| current_user.in_role? role }
+          redirect "/login/", 303
+        end
+      end
+    end
+
+    get "/mein/account/", :auth => [:user, :admin] do
+      "Mein Account"
+    end
+
+    get "/nur/admin/", :auth => :admin do
+      "Nur Admins dürfen hier rein!"
+    end
+```
+
+### Rückgabewerte
+
+Durch den Rückgabewert eines Routen-Blocks wird mindestens der Response-Body
+festgelegt, der an den HTTP-Client, bzw. die nächste Rack-Middleware,
+weitergegeben wird. Im Normalfall handelt es sich hierbei, wie in den
+vorangehenden Beispielen zu sehen war, um einen String. Es werden allerdings
+auch andere Werte akzeptiert.
+
+Es kann jedes gültige Objekt zurückgegeben werden, bei dem es sich entweder um
+einen Rack-Rückgabewert, einen Rack-Body oder einen HTTP-Status-Code handelt:
+
+*   Ein Array mit drei Elementen: `[Status (Fixnum), Headers (Hash),
+    Response-Body (antwortet auf #each)]`.
+*   Ein Array mit zwei Elementen: `[Status (Fixnum), Response-Body (antwortet
+    auf #each)]`.
+*   Ein Objekt, das auf `#each` antwortet und den an diese Methode übergebenen
+    Block nur mit Strings als Übergabewerte aufruft.
+*   Ein Fixnum, das den Status-Code festlegt.
+
+
+Damit lässt sich relativ einfach Streaming implementieren:
+
+```ruby
+    class Stream
+      def each
+        100.times { |i| yield "#{i}\n" }
+      end
+    end
+
+    get('/') { Stream.new }
+```
+
+Ebenso kann die `stream`-Helfer-Methode (s.u.) verwendet werden, die Streaming
+direkt in die Route integriert.
+
+### Eigene Routen-Muster
+
+Wie oben schon beschrieben, ist Sinatra von Haus aus mit Unterstützung für
+String-Muster und Reguläre Ausdrücke zum Abgleichen von Routen ausgestattet.
+Das muss aber noch nicht alles sein, es können ohne großen Aufwand eigene
+Routen-Muster erstellt werden:
+
+```ruby
+    class AllButPattern
+      Match = Struct.new(:captures)
+
+      def initialize(except)
+        @except   = except
+        @captures = Match.new([])
+      end
+
+      def match(str)
+        @captures unless @except === str
+      end
+    end
+
+    def all_but(pattern)
+      AllButPattern.new(pattern)
+    end
+
+    get all_but("/index") do
+      # ...
+    end
+```
+
+Beachte, dass das obige Beispiel etwas übertrieben wirkt. Es geht auch einfacher:
+
+```ruby
+    get // do
+      pass if request.path_info == "/index"
+      # ...
+    end
+```
+
+Oder unter Verwendung eines negativen look ahead:
+
+```ruby
+    get %r{^(?!/index$)} do
+      # ...
+    end
+```
+## Statische Dateien
+
+Statische Dateien werden aus dem `./public`-Ordner ausgeliefert. Es ist möglich,
+einen anderen Ort zu definieren, indem man die `:public_folder`-Option setzt:
+
+```ruby
+    set :public_folder, File.dirname(__FILE__) + '/static'
+```
+
+Zu beachten ist, dass der Ordnername public nicht Teil der URL ist. Die Datei
+`./public/css/style.css` ist unter `http://example.com/css/style.css` zu finden.
+
+Um den `Cache-Control`-Header mit Informationen zu versorgen, verwendet man
+die `:static_cache_control`-Einstellung (s.u.).
+
+## Views/Templates
+
+Alle Templatesprachen verwenden ihre eigene Renderingmethode, die jeweils
+einen String zurückgibt:
+
+```ruby
+    get '/' do
+      erb :index
+    end
+```
+
+Dieses Beispiel rendert `views/index.erb`.
+
+Anstelle eines Templatenamens kann man auch direkt die Templatesprache verwenden:
+
+```ruby
+    get '/' do
+      code = "<%= Time.now %>"
+      erb code
+    end
+```
+
+Templates nehmen ein zweite Argument an, den Options-Hash:
+
+```ruby
+    get '/' do
+      erb :index, :layout => :post
+    end
+```
+
+Dieses Beispiel rendert `views/index.erb` eingebettet in `views/post.erb`
+(Voreinstellung ist `views/layout.erb`, sofern es vorhanden ist.)
+
+Optionen, die Sinatra nicht versteht, werden an das Template weitergereicht:
+
+```ruby
+    get '/' do
+      haml :index, :format => :html5
+    end
+```
+
+Für alle Templates können auch generelle Einstellungen festgelegt werden:
+
+```ruby
+    set :haml, :format => :html5
+
+    get '/' do
+      haml :index
+    end
+```
+
+Optionen, die an die Rendermethode weitergegeben werden, überschreiben die
+Einstellungen, die mit `set` festgelegt wurden.
+
+Einstellungen:
+
+<dl>
+  <dt>locals</dt>
+  <dd>Liste von lokalen Variablen, die and das Dokument weitergegeben werden.
+    Praktisch für Partials. Beispiel:
+    <tt>erb "<%= foo %>", :locals => {:foo => "bar"}</tt></dd>
+      
+  <dt>default_encoding</dt>
+  <dd>Gibt die Stringkodierung an, die verwendet werden soll. Voreingestellt
+    auf <tt>settings.default_encoding</tt>.</dd>
+      
+  <dt>views</dt>
+  <dd>Ordner, aus dem die Templates heraus geladen werden. Voreingestellt auf
+    <tt>settings.views</tt>.</dd>
+      
+  <dt>layout</dt>
+  <dd>Legt fest, ob ein Layouttemplate verwendet werden soll oder nicht
+    (<tt>true</tt> oder<tt>false</tt>). Ist es ein Symbol, dass legt es fest,
+    welches Template als Layout verwendet wird. Beispiel:
+    <tt><tt>erb :index, :layout => !request.xhr?</tt></tt></dd>
+      
+  <dt>content_type</dt>
+  <dd>Content-Type den das Template ausgibt. Voreinstellung hängt von der
+    Templatesprache ab.</dd>
+      
+  <dt>scope</dt>
+  <dd>Scope, in dem das Template gerendert wird. Liegt standardmäßig innerhalb
+    der App-Instanz. Wird Scope geändert, sind Instanzvariablen und
+    Helfermethoden nicht verfügbar.</dd>
+      
+  <dt>layout_engine</dt>
+  <dd>Legt fest, welcher Renderer für das Layout verantwortlich ist. Hilfreich
+    für Sprachen, die sonst keine Templates unterstützen. Voreingestellt auf
+    den Renderer, der für das Template verwendet wird. Beispiel:
+    <tt>set :rdoc, :layout_engine => :erb</tt></dd>
+</dl>
+
+
+Sinatra geht davon aus, dass die Templates sich im `./views` Verzeichnis
+befinden. Es kann jedoch ein anderer Ordner festgelegt werden:
+
+```ruby
+    set :views, settings.root + '/templates'
+```
+
+Es ist zu beachten, dass immer mit Symbolen auf Templates verwiesen werden muss,
+auch dann, wenn sie sich in einem Unterordner befinden:
+
+```ruby
+    haml :'unterverzeichnis/template'
+```
+
+Rendering-Methoden rendern jeden String direkt.
+
+### Verfügbare Templatesprachen
+
+Einige Sprachen haben mehrere Implementierungen. Um festzulegen, welche
+verwendet wird (und dann auch Thread-sicher ist), verwendet man am besten zu
+Beginn ein 'require':
+
+```ruby
+    require 'rdiscount' # oder require 'bluecloth'
+    get('/') { markdown :index }
+```
+
+### Haml Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="http://haml.info/">haml</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.haml</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>haml :index, :format => :html5</tt></td>
+  </tr>
+</table>
+
+
+### Erb Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="http://www.kuwata-lab.com/erubis/">erubis</a> oder erb 
+    (Standardbibliothek von Ruby)</td>
+  </tr>
+  <tr>
+    <td>Dateierweiterungen</td>
+    <td><tt>.erb</tt>, <tt>.rhtml</tt> oder <tt>.erubis</tt> (nur Erubis)</td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>erb :index</tt></td>
+  </tr>
+</table>
+
+
+### Builder Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="http://builder.rubyforge.org/">builder</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.builder</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>builder { |xml| xml.em "Hallo" }</tt></td>
+  </tr>
+</table>
+
+Nimmt ebenso einen Block für Inline-Templates entgegen (siehe Beispiel).
+
+### Nokogiri Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="http://nokogiri.org/">nokogiri</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.nokogiri</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>nokogiri { |xml| xml.em "Hallo" }</tt></td>
+  </tr>
+</table>
+
+Nimmt ebenso einen Block für Inline-Templates entgegen (siehe Beispiel).
+
+### Sass Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="http://sass-lang.com/">sass</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.sass</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>sass :stylesheet, :style => :expanded</tt></td>
+  </tr>
+</table>
+
+
+### SCSS Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="http://sass-lang.com/">sass</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.scss</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>scss :stylesheet, :style => :expanded</tt></td>
+  </tr>
+</table>
+
+
+### Less Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="http://www.lesscss.org/">less</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.less</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>less :stylesheet</tt></td>
+  </tr>
+</table>
+
+
+### Liquid Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="http://www.liquidmarkup.org/">liquid</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.liquid</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>liquid :index, :locals => { :key => 'Wert' }</tt></td>
+  </tr>
+</table>
+
+Da man aus dem Liquid-Template heraus keine Ruby-Methoden aufrufen kann
+(ausgenommen `yield`), wird man üblicherweise locals verwenden wollen, mit
+denen man Variablen weitergibt.
+
+### Markdown Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td>Eine der folgenden Bibliotheken: 
+        <a href="https://github.com/rtomayko/rdiscount" title="RDiscount">RDiscount</a>,
+        <a href="https://github.com/vmg/redcarpet" title="RedCarpet">RedCarpet</a>,
+        <a href="http://deveiate.org/projects/BlueCloth" title="BlueCloth">BlueCloth</a>,
+        <a href="http://kramdown.rubyforge.org/" title="kramdown">kramdown</a> oder
+        <a href="http://maruku.rubyforge.org/" title="maruku">maruku</a>
+    </td>
+  </tr>
+  <tr>
+    <td>Dateierweiterungen</td>
+    <td><tt>.markdown</tt>, <tt>.mkd</tt> und <tt>.md</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>markdown :index, :layout_engine => :erb</tt></td>
+  </tr>
+</table>
+
+Da man aus den Markdown-Templates heraus keine Ruby-Methoden aufrufen und auch
+keine locals verwenden kann, wird man Markdown üblicherweise in Kombination
+mit anderen Renderern verwenden wollen:
+
+```ruby
+    erb :overview, :locals => { :text => markdown(:einfuehrung) }
+```
+
+Beachte, dass man die `markdown`-Methode auch aus anderen Templates heraus
+aufrufen kann:
+
+```ruby
+    %h1 Gruß von Haml!
+    %p= markdown(:Grüße)
+```
+
+Da man Ruby nicht von Markdown heraus aufrufen kann, können auch Layouts nicht
+in Markdown geschrieben werden. Es ist aber möglich, einen Renderer für die
+Templates zu verwenden und einen anderen für das Layout, indem die
+`:layout_engine`-Option verwendet wird.
+
+### Textile Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="http://redcloth.org/">RedCloth</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.textile</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>textile :index, :layout_engine => :erb</tt></td>
+  </tr>
+</table>
+
+Da man aus dem Textile-Template heraus keine Ruby-Methoden aufrufen und auch
+keine locals verwenden kann, wird man Textile üblicherweise in Kombination mit
+anderen Renderern verwenden wollen:
+
+```ruby
+    erb :overview, :locals => { :text => textile(:einfuehrung) }
+```
+
+Beachte, dass man die `textile`-Methode auch aus anderen Templates heraus
+aufrufen kann:
+
+```ruby
+    %h1 Gruß von Haml!
+    %p= textile(:Grüße)
+```
+
+Da man Ruby nicht von Textile heraus aufrufen kann, können auch Layouts nicht
+in Textile geschrieben werden. Es ist aber möglich, einen Renderer für die
+Templates zu verwenden und einen anderen für das Layout, indem die
+`:layout_engine`-Option verwendet wird.
+
+### RDoc Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="http://rdoc.rubyforge.org/">rdoc</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.rdoc</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>textile :README, :layout_engine => :erb</tt></td>
+  </tr>
+</table>
+
+Da man aus dem RDoc-Template heraus keine Ruby-Methoden aufrufen und auch
+keine locals verwenden kann, wird man RDoc üblicherweise in Kombination mit
+anderen Renderern verwenden wollen:
+
+```ruby
+    erb :overview, :locals => { :text => rdoc(:einfuehrung) }
+```
+
+Beachte, dass man die `rdoc`-Methode auch aus anderen Templates heraus
+aufrufen kann:
+
+```ruby
+    %h1 Gruß von Haml!
+    %p= rdoc(:Grüße)
+```
+
+Da man Ruby nicht von RDoc heraus aufrufen kann, können auch Layouts nicht in
+RDoc geschrieben werden. Es ist aber möglich, einen Renderer für die Templates
+zu verwenden und einen anderen für das Layout, indem die
+`:layout_engine`-Option verwendet wird.
+
+### Radius Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="http://radius.rubyforge.org/">radius</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.radius</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>radius :index, :locals => { :key => 'Wert' }</tt></td>
+  </tr>
+</table>
+
+Da man aus dem Radius-Template heraus keine Ruby-Methoden aufrufen kann, wird
+man üblicherweise locals verwenden wollen, mit denen man Variablen weitergibt.
+
+### Markaby Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="http://markaby.github.com/">markaby</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.mab</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>markaby { h1 "Willkommen!" }</tt></td>
+  </tr>
+</table>
+
+Nimmt ebenso einen Block für Inline-Templates entgegen (siehe Beispiel).
+
+### RABL Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="https://github.com/nesquena/rabl">rabl</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.rabl</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>rabl :index</tt></td>
+  </tr>
+</table>
+
+### Slim Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="http://slim-lang.com/">slim</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.slim</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>slim :index</tt></td>
+  </tr>
+</table>
+
+### Creole Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="https://github.com/minad/creole">creole</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.creole</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>creole :wiki, :layout_engine => :erb</tt></td>
+  </tr>
+</table>
+
+Da man aus dem Creole-Template heraus keine Ruby-Methoden aufrufen und auch
+keine locals verwenden kann, wird man Creole üblicherweise in Kombination mit
+anderen Renderern verwenden wollen:
+
+```ruby
+    erb :overview, :locals => { :text => creole(:einfuehrung) }
+```
+
+Beachte, dass man die `creole`-Methode auch aus anderen Templates heraus
+aufrufen kann:
+
+```ruby
+    %h1 Gruß von Haml!
+    %p= creole(:Grüße)
+```
+
+Da man Ruby nicht von Creole heraus aufrufen kann, können auch Layouts nicht in
+Creole geschrieben werden. Es ist aber möglich, einen Renderer für die Templates
+zu verwenden und einen anderen für das Layout, indem die `:layout_engine`-Option
+verwendet wird.
+
+### CoffeeScript Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="https://github.com/josh/ruby-coffee-script">coffee-script</a> und eine <a href="https://github.com/sstephenson/execjs/blob/master/README.md#readme">Möglichkeit JavaScript auszuführen</a>.</td>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.coffee</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>coffee :index</tt></td>
+  </tr>
+</table>
+
+### WLang Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="https://github.com/blambeau/wlang/">wlang</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.wlang</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>wlang :index, :locals => { :key => 'value' }</tt></td>
+  </tr>
+</table>
+
+Ruby-Methoden in wlang aufzurufen entspricht nicht den idiomatischen Vorgaben
+von wlang, es bietet sich deshalb an, `:locals` zu verwenden. Layouts, die
+wlang und `yield` verwenden, werden aber trotzdem unterstützt.
+
+### Eingebettete Templates
+
+```ruby
+    get '/' do
+      haml '%div.title Hallo Welt'
+    end
+```
+
+Rendert den eingebetteten Template-String.
+
+### Auf Variablen in Templates zugreifen
+
+Templates werden in demselben Kontext ausgeführt wie Routen. Instanzvariablen
+in Routen sind auch direkt im Template verfügbar:
+
+```ruby
+    get '/:id' do
+      @foo = Foo.find(params[:id])
+      haml '%h1= @foo.name'
+    end
+```
+
+Oder durch einen expliziten Hash von lokalen Variablen:
+
+```ruby
+    get '/:id' do
+      foo = Foo.find(params[:id])
+      haml '%h1= bar.name', :locals => { :bar => foo }
+    end
+```
+
+Dies wird typischerweise bei Verwendung von Subtemplates (partials) in anderen
+Templates eingesetzt.
+
+### Inline-Templates
+
+Templates können auch am Ende der Datei definiert werden:
+
+```ruby
+    require 'sinatra'
+
+    get '/' do
+      haml :index
+    end
+
+    __END__
+
+    @@ layout
+    %html
+      = yield
+
+    @@ index
+    %div.title Hallo Welt!!!!!
+```
+
+Anmerkung: Inline-Templates, die in der Datei definiert sind, die `require
+'sinatra'` aufruft, werden automatisch geladen. Um andere Inline-Templates in
+anderen Dateien aufzurufen, muss explizit `enable :inline_templates` verwendet
+werden.
+
+### Benannte Templates
+
+Templates können auch mit der Top-Level `template`-Methode definiert werden:
+
+```ruby
+    template :layout do
+      "%html\n  =yield\n"
+    end
+
+    template :index do
+      '%div.title Hallo Welt!'
+    end
+
+    get '/' do
+      haml :index
+    end
+```
+
+Wenn ein Template mit dem Namen "layout" existiert, wird es bei jedem Aufruf
+verwendet. Durch `:layout => false` kann das Ausführen verhindert werden:
+
+```ruby
+    get '/' do
+      haml :index, :layout => request.xhr?
+    end
+```
+
+### Dateiendungen zuordnen
+
+Um eine Dateiendung einer Template-Engine zuzuordnen, kann `Tilt.register`
+genutzt werden. Wenn etwa die Dateiendung `tt` für Textile-Templates genutzt
+werden soll, lässt sich dies wie folgt bewerkstelligen:
+
+```ruby
+    Tilt.register :tt, Tilt[:textile]
+```
+
+### Eine eigene Template-Engine hinzufügen
+
+Zu allererst muss die Engine bei Tilt registriert und danach eine
+Rendering-Methode erstellt werden:
+
+```ruby
+    Tilt.register :mtt, MeineTolleTemplateEngine
+
+    helpers do
+      def mtt(*args) render(:mtt, *args) end
+    end
+
+    get '/' do
+      mtt :index
+    end
+```
+
+Dieser Code rendert `./views/application.mtt`. Siehe
+[github.com/rtomayko/tilt](https://github.com/rtomayko/tilt), um mehr über
+Tilt zu erfahren.
+
+## Filter
+
+Before-Filter werden vor jedem Request in demselben Kontext, wie danach die
+Routen, ausgeführt. So können etwa Request und Antwort geändert werden.
+Gesetzte Instanzvariablen in Filtern können in Routen und Templates verwendet
+werden:
+
+```ruby
+    before do
+      @note = 'Hi!'
+      request.path_info = '/foo/bar/baz'
+    end
+
+    get '/foo/*' do
+      @note #=> 'Hi!'
+      params[:splat] #=> 'bar/baz'
+    end
+```
+
+After-Filter werden nach jedem Request in demselben Kontext ausgeführt und
+können ebenfalls Request und Antwort ändern. In Before-Filtern gesetzte
+Instanzvariablen können in After-Filtern verwendet werden:
+
+```ruby
+    after do
+      puts response.status
+    end
+```
+
+Filter können optional auch mit einem Muster ausgestattet werden, welches auf
+den Request-Pfad passen muss, damit der Filter ausgeführt wird:
+
+```ruby
+    before '/protected/*' do
+      authenticate!
+    end
+
+    after '/create/:slug' do |slug|
+      session[:last_slug] = slug
+    end
+```
+
+Ähnlich wie Routen können Filter auch mit weiteren Bedingungen eingeschränkt
+werden:
+
+```ruby
+    before :agent => /Songbird/ do
+      # ...
+    end
+
+    after '/blog/*', :host_name => 'example.com' do
+      # ...
+    end
+```
+
+## Helfer
+
+Durch die Top-Level `helpers`-Methode werden sogenannte Helfer-Methoden
+definiert, die in Routen und Templates verwendet werden können:
+
+```ruby
+    helpers do
+      def bar(name)
+        "#{name}bar"
+      end
+    end
+
+    get '/:name' do
+      bar(params[:name])
+    end
+```
+
+### Sessions verwenden
+Sessions werden verwendet, um Zustände zwischen den Requests zu speichern. Sind
+sie aktiviert, kann ein Session-Hash je Benutzer-Session verwendet werden:
+
+```ruby
+    enable :sessions
+
+    get '/' do
+      "value = " << session[:value].inspect
+    end
+
+    get '/:value' do
+      session[:value] = params[:value]
+    end
+```
+
+Beachte, dass `enable :sessions` alle Daten in einem Cookie speichert. Unter
+Umständen kann dies negative Effekte haben, z.B. verursachen viele Daten
+höheren, teilweise überflüssigen Traffic. Um das zu vermeiden, kann eine Rack-
+Session-Middleware verwendet werden. Dabei wird auf `enable :sessions`
+verzichtet und die Middleware wie üblich im Programm eingebunden:
+
+```ruby
+    use Rack::Session::Pool, :expire_after => 2592000
+
+    get '/' do
+      "value = " << session[:value].inspect
+    end
+
+    get '/:value' do
+      session[:value] = params[:value]
+    end
+```
+
+Um die Sicherheit zu erhöhen, werden Cookies, die Session-Daten führen, mit
+einem sogenannten Session-Secret signiert. Da sich dieses Geheimwort bei jedem
+Neustart der Applikation automatisch ändert, ist es sinnvoll, ein eigenes zu
+wählen, damit sich alle Instanzen der Applikation dasselbe Session-Secret
+teilen:
+
+```ruby
+    set :session_secret, 'super secret'
+```
+
+Zur weiteren Konfiguration kann man einen Hash mit Optionen in den `sessions`
+Einstellungen ablegen.
+
+```ruby
+    set :sessions, :domain => 'foo.com'
+```
+
+## Anhalten
+
+Zum sofortigen Stoppen eines Request in einem Filter oder einer Route:
+
+```ruby
+    halt
+```
+
+Der Status kann beim Stoppen auch angegeben werden:
+
+```ruby
+    halt 410
+```
+
+Oder auch den Response-Body:
+
+```ruby
+    halt 'Hier steht der Body'
+```
+
+Oder beides:
+
+```ruby
+    halt 401, 'verschwinde!'
+```
+
+Sogar mit Headern:
+
+```ruby
+    halt 402, {'Content-Type' => 'text/plain'}, 'Rache'
+```
+
+Natürlich ist es auch möglich, ein Template mit `halt` zu verwenden:
+
+```ruby
+    halt erb(:error)
+```
+
+## Weiterspringen
+
+Eine Route kann mittels `pass` zu der nächsten passenden Route springen:
+
+```ruby
+    get '/raten/:wer' do
+      pass unless params[:wer] == 'Frank'
+      'Du hast mich!'
+    end
+
+    get '/raten/*' do
+      'Du hast mich nicht!'
+    end
+```
+
+Der Block wird sofort verlassen und es wird nach der nächsten treffenden Route
+gesucht. Ein 404-Fehler wird zurückgegeben, wenn kein treffendes Routen-Muster
+gefunden wird.
+
+### Eine andere Route ansteuern
+
+Manchmal entspricht `pass` nicht den Anforderungen, wenn das Ergebnis einer
+anderen Route gefordert wird. Um das zu erreichen, lässt sich `call` nutzen:
+
+```ruby
+    get '/foo' do
+      status, headers, body = call env.merge("PATH_INFO" => '/bar')
+      [status, headers, body.map(&:upcase)]
+    end
+
+    get '/bar' do
+      "bar"
+    end
+```
+
+Beachte, dass in dem oben angegeben Beispiel die Performance erheblich erhöht
+werden kann, wenn `"bar"` in eine Helfer-Methode umgewandelt wird, auf die
+`/foo` und `/bar` zugreifen können.
+
+Wenn der Request innerhalb derselben Applikations-Instanz aufgerufen und keine
+Kopie der Instanz erzeugt werden soll, kann `call!` anstelle von `call`
+verwendet werden.
+
+Die Rack-Spezifikationen enthalten weitere Informationen zu `call`.
+
+### Body, Status-Code und Header setzen
+
+Es ist möglich und empfohlen, den Status-Code sowie den Response-Body mit
+einem Returnwert in der Route zu setzen. In manchen Situationen kann es jedoch
+sein, dass der Body an irgendeiner anderen Stelle während der Ausführung
+gesetzt wird. Das lässt sich mit der Helfer-Methode `body` bewerkstelligen.
+Wird `body` verwendet, lässt sich der Body jederzeit über diese Methode
+aufrufen:
+
+```ruby
+    get '/foo' do
+      body "bar"
+    end
+
+    after do
+      puts body
+    end
+```
+
+Ebenso ist es möglich, einen Block an `body` weiterzureichen, der dann vom
+Rack-Handler ausgeführt wird (lässt sich z.B. zur Umsetzung von Streaming
+einsetzen, siehe auch "Rückgabewerte").
+
+Vergleichbar mit `body` lassen sich auch Status-Code und Header setzen:
+
+```ruby
+    get '/foo' do
+      status 418
+      headers \
+        "Allow"   => "BREW, POST, GET, PROPFIND, WHEN",
+        "Refresh" => "Refresh: 20; http://www.ietf.org/rfc/rfc2324.txt"
+      halt "Ich bin ein Teekesselchen"
+    end
+```
+
+Genau wie bei `body` liest ein Aufrufen von `headers` oder `status` ohne
+Argumente den aktuellen Wert aus.
+
+### Response-Streams
+
+In manchen Situationen sollen Daten bereits an den Client zurückgeschickt
+werden, bevor ein vollständiger Response bereit steht. Manchmal will man die
+Verbindung auch erst dann beenden und Daten so lange an den Client
+zurückschicken, bis er die Verbindung abbricht. Für diese Fälle gibt es die
+`stream`-Helfer-Methode, die es einem erspart eigene Lösungen zu schreiben:
+
+```ruby
+    get '/' do
+      stream do |out|
+        out << "Das ist ja mal wieder fanta -\n"
+        sleep 0.5
+        out << " (bitte warten…) \n"
+        sleep 1
+        out << "- stisch!\n"
+      end
+    end
+```
+
+Damit lassen sich Streaming-APIs realisieren, sog. 
+[Server Sent Events](http://dev.w3.org/html5/eventsource/) die als Basis für
+[WebSockets](http://en.wikipedia.org/wiki/WebSocket) dienen. Ebenso können sie
+verwendet werden, um den Durchsatz zu erhöhen, wenn ein Teil der Daten von
+langsamen Ressourcen abhängig ist.
+
+Es ist zu beachten, dass das Verhalten beim Streaming, insbesondere die Anzahl
+nebenläufiger Anfragen, stark davon abhängt, welcher Webserver für die
+Applikation verwendet wird. Einige Server, z.B. WEBRick, unterstützen
+Streaming nicht oder nur teilweise. Sollte der Server Streaming nicht
+unterstützen, wird ein vollständiger Response-Body zurückgeschickt, sobald der
+an `stream` weitergegebene Block abgearbeitet ist. Mit Shotgun funktioniert
+Streaming z.B. überhaupt nicht.
+
+Ist der optionale Parameter `keep_open` aktiviert, wird beim gestreamten Objekt
+`close` nicht aufgerufen und es ist einem überlassen dies an einem beliebigen
+späteren Zeitpunkt nachholen. Die Funktion ist jedoch nur bei Event-gesteuerten
+Serven wie Thin oder Rainbows möglich, andere Server werden trotzdem den Stream
+beenden:
+
+```ruby
+    set :server, :thin
+    connections = []
+
+    get '/' do
+      # Den Stream offen halten
+      stream(:keep_open) { |out| connections << out }
+    end
+
+    post '/' do
+      # In alle offenen Streams schreiben
+      connections.each { |out| out << params[:message] << "\n" }
+      "Nachricht verschickt"
+    end
+```
+
+### Logger
+
+Im Geltungsbereich eines Request stellt die `logger` Helfer-Methode eine `Logger`
+Instanz zur Verfügung:
+
+```ruby
+    get '/' do
+      logger.info "es passiert gerade etwas"
+      # ...
+    end
+```
+
+Der Logger übernimmt dabei automatisch alle im Rack-Handler eingestellten 
+Log-Vorgaben. Ist Loggen ausgeschaltet, gibt die Methode ein Leerobjekt zurück.
+In den Routen und Filtern muss man sich also nicht weiter darum kümmern.
+
+Beachte, dass das Loggen standardmäßig nur für `Sinatra::Application`
+voreingestellt ist. Wird über `Sinatra::Base` vererbt, muss es erst aktiviert
+werden:
+
+```ruby
+    class MyApp < Sinatra::Base
+      configure :production, :development  do
+        enable :logging
+      end
+    end
+```
+
+Damit auch keine Middleware das Logging aktivieren kann, muss die `logging`
+Einstellung auf `nil` gesetzt werden. Das heißt aber auch, dass `logger` in
+diesem Fall `nil` zurückgeben wird. Üblicherweise wird das eingesetzt, wenn ein
+eigener Logger eingerichtet werden soll. Sinatra wird dann verwenden, was in 
+`env['rack.logger']` eingetragen ist.
+
+## Mime-Types
+
+Wenn `send_file` oder statische Dateien verwendet werden, kann es vorkommen,
+dass Sinatra den Mime-Typ nicht kennt. Registriert wird dieser mit `mime_type`
+per Dateiendung:
+
+```ruby
+    configure do
+      mime_type :foo, 'text/foo'
+    end
+```
+
+Es kann aber auch der `content_type`-Helfer verwendet werden:
+
+```ruby
+    get '/' do
+      content_type :foo
+      "foo foo foo"
+    end
+```
+
+### URLs generieren
+
+Zum Generieren von URLs sollte die `url`-Helfer-Methode genutzen werden, so z.B.
+beim Einsatz von Haml:
+
+```ruby
+    %a{:href => url('/foo')} foo
+```
+
+Soweit vorhanden, wird Rücksicht auf Proxys und Rack-Router genommen.
+
+Diese Methode ist ebenso über das Alias `to` zu erreichen (siehe Beispiel unten).
+
+### Browser-Umleitung
+
+Eine Browser-Umleitung kann mithilfe der `redirect`-Helfer-Methode erreicht
+werden:
+
+```ruby
+    get '/foo' do
+      redirect to('/bar')
+    end
+```
+
+Weitere Parameter werden wie Argumente der `halt`-Methode behandelt:
+
+```ruby
+    redirect to('/bar'), 303
+    redirect 'http://google.com', 'Hier bist du falsch'
+```
+
+Ebenso leicht lässt sich ein Schritt zurück mit dem Alias `redirect back`
+erreichen:
+
+```ruby
+    get '/foo' do
+      "<a href='/bar'>mach was</a>"
+    end
+
+    get '/bar' do
+      mach_was
+      redirect back
+    end
+```
+
+Um Argumente an ein Redirect weiterzugeben, können sie entweder dem Query
+übergeben:
+
+```ruby
+    redirect to('/bar?summe=42')
+```
+
+oder eine Session verwendet werden:
+
+```ruby
+    enable :sessions
+
+    get '/foo' do
+      session[:secret] = 'foo'
+      redirect to('/bar')
+    end
+
+    get '/bar' do
+      session[:secret]
+    end
+```
+
+### Cache einsetzen
+
+Ein sinnvolles Einstellen von Header-Daten ist die Grundlage für ein
+ordentliches HTTP-Caching.
+
+Der Cache-Control-Header lässt sich ganz einfach einstellen:
+
+```ruby
+    get '/' do
+      cache_control :public
+      "schon gecached!"
+    end
+```
+
+Profitipp: Caching im before-Filter aktivieren
+
+```ruby
+    before do
+      cache_control :public, :must_revalidate, :max_age => 60
+    end
+```
+
+Bei Verwendung der `expires`-Helfermethode zum Setzen des gleichnamigen Headers,
+wird `Cache-Control` automatisch eigestellt:
+
+```ruby
+    before do
+      expires 500, :public, :must_revalidate
+    end
+```
+
+Um alles richtig zu machen, sollten auch `etag` oder `last_modified` verwendet
+werden. Es wird empfohlen, dass diese Helfer aufgerufen werden **bevor** die
+eigentliche Arbeit anfängt, da sie sofort eine Antwort senden, wenn der Client
+eine aktuelle Version im Cache vorhält:
+
+```ruby
+    get '/article/:id' do
+      @article = Article.find params[:id]
+      last_modified @article.updated_at
+      etag @article.sha1
+      erb :article
+    end
+```
+
+ebenso ist es möglich einen 
+[schwachen ETag](http://de.wikipedia.org/wiki/HTTP_ETag) zu verwenden:
+
+```ruby
+    etag @article.sha1, :weak
+```
+
+Diese Helfer führen nicht das eigentliche Caching aus, sondern geben die dafür
+notwendigen Informationen an den Cache weiter. Für schnelle Reverse-Proxy
+Cache-Lösungen bietet sich z.B.
+[rack-cache](https://github.com/rtomayko/rack-cache) an:
+
+```ruby
+    require "rack/cache"
+    require "sinatra"
+
+    use Rack::Cache
+
+    get '/' do
+      cache_control :public, :max_age => 36000
+      sleep 5
+      "hello"
+    end
+```
+
+Um den `Cache-Control`-Header mit Informationen zu versorgen, verwendet man die
+`:static_cache_control`-Einstellung (s.u.).
+
+Nach RFC 2616 sollte sich die Anwendung anders verhalten, wenn ein If-Match oder
+ein If-None_match Header auf `*` gesetzt wird in Abhängigkeit davon, ob die
+Resource bereits existiert. Sinatra geht davon aus, dass Ressourcen bei sicheren
+Anfragen (z.B. bei get oder Idempotenten Anfragen wie put) bereits existieren,
+wobei anderen Ressourcen (besipielsweise bei post), als neue Ressourcen
+behandelt werden. Dieses Verhalten lässt sich mit der `:new_resource` Option
+ändern:
+
+```ruby
+    get '/create' do
+      etag '', :new_resource => true
+      Article.create
+      erb :new_article
+    end
+```
+
+Soll das schwache ETag trotzdem verwendet werden, verwendet man die `:kind`
+Option:
+
+```ruby
+    etag '', :new_resource => true, :kind => :weak
+```
+
+### Dateien versenden
+
+Zum Versenden von Dateien kann die `send_file`-Helfer-Methode verwendet werden:
+
+```ruby
+    get '/' do
+      send_file 'foo.png'
+    end
+```
+
+Für `send_file` stehen einige Hash-Optionen zur Verfügung:
+
+```ruby
+    send_file 'foo.png', :type => :jpg
+```
+
+<dl>
+  <dt>filename</dt>
+  <dd>Dateiname als Response. Standardwert ist der eigentliche Dateiname.</dd>
+
+  <dt>last_modified</dt>
+  <dd>Wert für den Last-Modified-Header, Standardwert ist <tt>mtime</tt> der
+    Datei.</dd>
+  
+  <dt>type</dt>
+  <dd>Content-Type, der verwendet werden soll. Wird, wenn nicht angegeben, von
+    der Dateiendung abgeleitet.</dd>
+  
+  <dt>disposition</dt>
+  <dd>Verwendet für Content-Disposition. Mögliche Werte sind: <tt>nil</tt>
+    (Standard), <tt>:attachment</tt> und <tt>:inline</tt>.</dd>
+  
+  <dt>length</dt>
+  <dd>Content-Length-Header. Standardwert ist die Dateigröße.</dd>
+</dl>
+
+Soweit vom Rack-Handler unterstützt, werden neben der Übertragung über den
+Ruby-Prozess auch andere Möglichkeiten genutzt. Bei Verwendung der
+`send_file`-Helfer-Methode kümmert sich Sinatra selbstständig um die
+Range-Requests.
+
+## Das Request-Objekt
+
+Auf das `request`-Objekt der eigehenden Anfrage kann vom Anfrage-Scope aus
+zugegriffen werden:
+
+```ruby
+    # App läuft unter http://example.com/example
+    get '/foo' do
+      t = %w[text/css text/html application/javascript]
+      request.accept              # ['text/html', '*/*']
+      request.accept? 'text/xml'  # true
+      request.preferred_type(t)   # 'text/html'
+      request.body                # Request-Body des Client (siehe unten)
+      request.scheme              # "http"
+      request.script_name         # "/example"
+      request.path_info           # "/foo"
+      request.port                # 80
+      request.request_method      # "GET"
+      request.query_string        # ""
+      request.content_length      # Länge des request.body
+      request.media_type          # Medientypus von request.body
+      request.host                # "example.com"
+      request.get?                # true (ähnliche Methoden für andere Verben)
+      request.form_data?          # false
+      request["IRGENDEIN_HEADER"] # Wert von IRGENDEIN_HEADER header
+      request.referrer            # Der Referrer des Clients oder '/'
+      request.user_agent          # User-Agent (verwendet in der :agent Bedingung)
+      request.cookies             # Hash des Browser-Cookies
+      request.xhr?                # Ist das hier ein Ajax-Request?
+      request.url                 # "http://example.com/example/foo"
+      request.path                # "/example/foo"
+      request.ip                  # IP-Adresse des Clients
+      request.secure?             # false (true wenn SSL)
+      request.forwarded?          # true (Wenn es hinter einem Reverse-Proxy verwendet wird)
+      request.env                 # vollständiger env-Hash von Rack übergeben
+    end
+```
+
+Manche Optionen, wie etwa `script_name` oder `path_info`, sind auch
+schreibbar:
+
+```ruby
+    before { request.path_info = "/" }
+
+    get "/" do
+      "Alle Anfragen kommen hier an!"
+    end
+```
+
+Der `request.body` ist ein IO- oder StringIO-Objekt:
+
+```ruby
+    post "/api" do
+      request.body.rewind # falls schon jemand davon gelesen hat
+      daten = JSON.parse request.body.read
+      "Hallo #{daten['name']}!"
+    end
+```
+
+### Anhänge
+
+Damit der Browser erkennt, dass ein Response gespeichert und nicht im Browser
+angezeigt werden soll, kann der `attachment`-Helfer verwendet werden:
+
+```ruby
+    get '/' do
+      attachment
+      "Speichern!"
+    end
+```
+
+Ebenso kann eine Dateiname als Parameter hinzugefügt werden:
+
+```ruby
+    get '/' do
+      attachment "info.txt"
+      "Speichern!"
+    end
+```
+
+### Umgang mit Datum und Zeit
+
+Sinatra bietet eine `time_for`-Helfer-Methode, die aus einem gegebenen Wert ein
+Time-Objekt generiert. Ebenso kann sie nach `DateTime`, `Date` und ähnliche
+Klassen konvertieren:
+
+```ruby
+    get '/' do
+      pass if Time.now > time_for('Dec 23, 2012')
+      "noch Zeit"
+    end
+```
+
+Diese Methode wird intern für +expires, `last_modiefied` und ihresgleichen
+verwendet. Mit ein paar Handgriffen lässt sich diese Methode also in ihrem
+Verhalten erweitern, indem man `time_for` in der eigenen Applikation 
+überschreibt:
+
+```ruby
+    helpers do
+      def time_for(value)
+        case value
+        when :yesterday then Time.now - 24*60*60
+        when :tomorrow  then Time.now + 24*60*60
+        else super
+        end
+      end
+    end
+
+    get '/' do
+      last_modified :yesterday
+      expires :tomorrow
+      "Hallo"
+    end
+```
+
+### Nachschlagen von Template-Dateien
+
+Die `find_template`-Helfer-Methode wird genutzt, um Template-Dateien zum Rendern
+aufzufinden:
+
+```ruby
+    find_template settings.views, 'foo', Tilt[:haml] do |file|
+      puts "könnte diese hier sein: #{file}"
+    end
+```
+
+Das ist zwar nicht wirklich brauchbar, aber wenn man sie überschreibt, kann sie
+nützlich werden, um eigene Nachschlage-Mechanismen einzubauen. Zum Beispiel
+dann, wenn mehr als nur ein view-Verzeichnis verwendet werden soll:
+
+```ruby
+    set :views, ['views', 'templates']
+
+    helpers do
+      def find_template(views, name, engine, &block)
+        Array(views).each { |v| super(v, name, engine, &block) }
+      end
+    end
+```
+
+Ein anderes Beispiel wäre, verschiedene Vereichnisse für verschiedene Engines
+zu verwenden:
+
+```ruby
+    set :views, :sass => 'views/sass', :haml => 'templates', :default => 'views'
+
+    helpers do
+      def find_template(views, name, engine, &block)
+        _, folder = views.detect { |k,v| engine == Tilt[k] }
+        folder ||= views[:default]
+        super(folder, name, engine, &block)
+      end
+    end
+```
+
+Ebensogut könnte eine Extension aber auch geschrieben und mit anderen geteilt
+werden!
+
+Beachte, dass `find_template` nicht prüft, ob eine Datei tatsächlich existiert.
+Es wird lediglich der angegebene Block aufgerufen und nach allen möglichen
+Pfaden gesucht. Das ergibt kein Performance-Problem, da `render` `block` 
+verwendet, sobald eine Datei gefunden wurde. Ebenso werden Template-Pfade samt
+Inhalt gecached, solange nicht im Entwicklungsmodus gearbeitet wird. Das sollte
+im Hinterkopf behalten werden, wenn irgendwelche verrückten Methoden
+zusammenbastelt werden.
+
+## Konfiguration
+
+Wird einmal beim Starten in jedweder Umgebung ausgeführt:
+
+```ruby
+    configure do
+      # setze eine Option
+      set :option, 'wert'
+
+      # setze mehrere Optionen
+      set :a => 1, :b => 2
+
+      # das gleiche wie `set :option, true`
+      enable :option
+
+      # das gleiche wie `set :option, false`
+      disable :option
+
+      # dynamische Einstellungen mit Blöcken
+      set(:css_dir) { File.join(views, 'css') }
+    end
+```
+
+Läuft nur, wenn die Umgebung (RACK_ENV-Umgebungsvariable) auf `:production`
+gesetzt ist:
+
+```ruby
+    configure :production do
+      ...
+    end
+```
+
+Läuft nur, wenn die Umgebung auf `:production` oder auf `:test` gesetzt ist:
+
+```ruby
+    configure :production, :test do
+      ...
+    end
+```
+
+Diese Einstellungen sind über `settings` erreichbar:
+
+```ruby
+    configure do
+      set :foo, 'bar'
+    end
+
+    get '/' do
+      settings.foo? # => true
+      settings.foo  # => 'bar'
+      ...
+    end
+```
+
+### Einstellung des Angriffsschutzes
+
+Sinatra verwendet
+[Rack::Protection](https://github.com/rkh/rack-protection#readme), um die
+Anwendung vor häufig vorkommenden Angriffen zu schützen. Diese Voreinstellung
+lässt sich selbstverständlich deaktivieren, der damit verbundene
+Geschwindigkeitszuwachs steht aber in keinem Verhätnis zu den möglichen
+Risiken.
+
+```ruby
+    disable :protection
+```
+
+Um einen bestimmten Schutzmechanismus zu deaktivieren, fügt man `protection`
+einen Hash mit Optionen hinzu:
+
+```ruby
+    set :protection, :except => :path_traversal
+```
+
+Neben Strings akzeptiert `:except` auch Arrays, um gleich mehrere
+Schutzmechanismen zu deaktivieren:
+
+```ruby
+    set :protection, :except => [:path_traversal, :session_hijacking]
+```
+## Möglichee Einstellungen
+
+<dl>
+  <dt>absolute_redirects</dt>
+  <dd>Wenn ausgeschaltet, wird Sinatra relative Redirects zulassen. Jedoch ist
+  Sinatra dann nicht mehr mit RFC 2616 (HTTP 1.1) konform, das nur absolute
+  Redirects zulässt. Sollte eingeschaltet werden, wenn die Applikation hinter
+  einem Reverse-Proxy liegt, der nicht ordentlich eingerichtet ist. Beachte,
+  dass die <tt>url</tt>-Helfer-Methode nach wie vor absolute URLs erstellen
+  wird, es sei denn, es wird als zweiter Parameter <tt>false</tt> angegeben.
+  Standardmäßig nicht aktiviert.</dd>
+
+  <dt>add_charsets</dt>
+  <dd>
+    Mime-Types werden hier automatisch der Helfer-Methode <tt>content_type</tt>
+    zugeordnet. Es empfielt sich, Werte hinzuzufügen statt sie zu
+    überschreiben: <tt>settings.add_charsets << "application/foobar"</tt>
+  </dd>
+
+  <dt>app_file</dt>
+  <dd>Pfad zur Hauptdatei der Applikation. Wird verwendet, um das Wurzel-,
+  Inline-, View- und öffentliche Verzeichnis des Projekts festzustellen.</dd>
+
+  <dt>bind</dt>
+  <dd>IP-Address, an die gebunden wird (Standardwert: 0.0.0.0). Wird nur für
+  den eingebauten Server verwendet.</dd>
+
+  <dt>default_encoding</dt>
+  <dd>Das Encoding, falls keines angegeben wurde. Standardwert ist
+  <tt>"utf-8"</tt>.</dd>
+
+  <dt>dump_errors</dt>
+  <dd>Fehler im Log anzeigen.</dd>
+
+  <dt>environment</dt>
+  <dd>Momentane Umgebung. Standardmäßig auf <tt>content_type</tt> oder
+  <tt>"development"</tt> eingestellt, soweit ersteres nicht vorhanden.</dd>
+
+  <dt>logging</dt>
+  <dd>Den Logger verwenden.</dd>
+
+  <dt>lock</dt>
+  <dd>Jeder Request wird gelocked. Es kann nur ein Request pro Ruby-Prozess
+  gleichzeitig verarbeitet werden. Eingeschaltet, wenn die Applikation
+  threadsicher ist. Standardmäßig nicht aktiviert.</dd>
+
+  <dt>method_override</dt>
+  <dd>Verwende <tt>_method</tt>, um put/delete-Formulardaten in Browsern zu
+  verwenden, die dies normalerweise nicht unterstützen.</dd>
+
+  <dt>port</dt>
+  <dd>Port für die Applikation. Wird nur im internen Server verwendet.</dd>
+
+  <dt>prefixed_redirects</dt>
+  <dd>Entscheidet, ob <tt>request.script_name</tt> in Redirects eingefügt wird
+  oder nicht, wenn kein absoluter Pfad angegeben ist. Auf diese Weise verhält
+  sich <tt>redirect '/foo'</tt> so, als wäre es ein <tt>redirect
+  to('/foo')</tt>. Standardmäßig nicht aktiviert.</dd>
+
+  <dt>protection</dt>
+  <dd>Legt fest, ob der Schutzmechanismus für häufig Vorkommende Webangriffe
+  auf Webapplikationen aktiviert wird oder nicht. Weitere Informationen im
+  vorhergehenden Abschnitt.</dd>
+
+  <dt>public_folder</dt>
+  <dd>Das öffentliche Verzeichnis, aus dem Daten zur Verfügung gestellt werden
+  können. Wird nur dann verwendet, wenn statische Daten zur Verfügung gestellt
+  werden können (s.u. <tt>static</tt> Option). Leitet sich von der
+  <tt>app_file</tt> Einstellung ab, wenn nicht gesetzt.</dd>
+
+  <dt>public_dir</dt>
+  <dd>Alias für <tt>public_folder</tt>, s.o.</dd>
+
+  <dt>reload_templates</dt>
+  <dd>Im development-Modus aktiviert.</dd>
+
+  <dt>root</dt>
+  <dd>Wurzelverzeichnis des Projekts. Leitet sich von der <tt>app_file</tt>
+  Einstellung ab, wenn nicht gesetzt.</dd>
+
+  <dt>raise_errors</dt>
+  <dd>Einen Ausnahmezustand aufrufen. Beendet die Applikation. Ist automatisch
+  aktiviert, wenn die Umgebung auf <tt>"test"</tt> eingestellt ist. Ansonsten
+  ist diese Option deaktiviert.</dd>
+
+  <dt>run</dt>
+  <dd>Wenn aktiviert, wird Sinatra versuchen, den Webserver zu starten. Nicht
+  verwenden, wenn Rackup oder anderes verwendet werden soll.</dd>
+
+  <dt>running</dt>
+  <dd>Läuft der eingebaute Server? Diese Einstellung nicht ändern!</dd>
+
+  <dt>server</dt>
+  <dd>Server oder Liste von Servern, die als eingebaute Server zur Verfügung
+  stehen. Standardmäßig auf [‘thin’, ‘mongrel’, ‘webrick’] voreingestellt. Die
+  Anordnung gibt die Priorität
+  vor.</dd>
+
+  <dt>sessions</dt>
+  <dd>Sessions auf Cookiebasis mittels
+  <tt>Rack::Session::Cookie</tt>aktivieren. Für weitere Infos bitte in der
+  Sektion ‘Sessions verwenden’ nachschauen.</dd>
+
+  <dt>show_exceptions</dt>
+  <dd>Bei Fehlern einen Stacktrace im Browseranzeigen. Ist automatisch
+  aktiviert, wenn die Umgebung auf <tt>"development"</tt> eingestellt ist.
+  Ansonsten ist diese Option deaktiviert. Kann auch auf <tt>:after_handler</tt>
+  gestellt werden, um eine anwendungsspezifische Fehlerbehandlung auszulösen,
+  bevor der Fehlerverlauf im Browser angezeigt wird.</dd>
+
+  <dt>static</dt>
+  <dd>Entscheidet, ob Sinatra statische Dateien zur Verfügung stellen soll oder
+  nicht. Sollte nicht aktiviert werden, wenn ein Server verwendet wird, der
+  dies auch selbstständig erledigen kann. Deaktivieren wird die Performance
+  erhöhen. Standardmäßig aktiviert.</dd>
+
+  <dt>static_cache_control</dt>
+  <dd>Wenn Sinatra statische Daten zur Verfügung stellt, können mit dieser
+  Einstellung die <tt>Cache-Control</tt> Header zu den Responses hinzugefügt
+  werden. Die Einstellung verwendet dazu die <tt>cache_control</tt>
+  Helfer-Methode. Standardmäßig deaktiviert. Ein Array wird verwendet, um
+  mehrere Werte gleichzeitig zu übergeben: <tt>set :static_cache_control,
+  [:public, :max_age => 300]</tt></dd>
+
+  <dt>views</dt>
+  <dd>Verzeichnis der Views. Leitet sich von der <tt>app_file</tt> Einstellung
+  ab, wenn nicht gesetzt.</dd>
+</dl>
+
+## Umgebungen
+
+Es gibt drei voreingestellte Umgebungen in Sinatra: `"development"`,
+`"production"` und `"test"`. Umgebungen können über die `RACK_ENV`
+Umgebungsvariable gesetzt werden. Die Standardeinstellung ist `"development"`.
+In diesem Modus werden alle Templates zwischen Requests neu geladen. Dazu gibt
+es besondere Fehlerseiten für 404 Stati und Fehlermeldungen. In `"production"`
+und `"test"` werden Templates automatisch gecached.
+
+Um die Anwendung in einer anderen Umgebung auszuführen kann man die `-e`
+Option verwenden:
+
+```
+    ruby my_app.rb -e [ENVIRONMENT]
+```
+
+In der Anwendung kann man die die Methoden  `development?`, `test?` und
+`production?` verwenden, um die aktuelle Umgebung zu erfahren.
+
+## Fehlerbehandlung
+
+Error-Handler laufen in demselben Kontext wie Routen und Filter, was bedeutet,
+dass alle Goodies wie `haml`, `erb`, `halt`, etc. verwendet werden können.
+
+### Nicht gefunden
+
+Wenn eine `Sinatra::NotFound`-Exception geworfen wird oder der Statuscode 404
+ist, wird der `not_found`-Handler ausgeführt:
+
+```ruby
+    not_found do
+      'Seite kann nirgendwo gefunden werden.'
+    end
+```
+
+### Fehler
+
+Der `error`-Handler wird immer ausgeführt, wenn eine Exception in einem
+Routen-Block oder in einem Filter geworfen wurde. Die Exception kann über die
+`sinatra.error`-Rack-Variable angesprochen werden:
+
+```ruby
+    error do
+      'Entschuldige, es gab einen hässlichen Fehler - ' + env['sinatra.error'].name
+    end
+```
+
+Benutzerdefinierte Fehler:
+
+```ruby
+    error MeinFehler do
+      'Au weia, ' + env['sinatra.error'].message
+    end
+```
+
+Dann, wenn das passiert:
+
+```ruby
+    get '/' do
+      raise MeinFehler, 'etwas Schlimmes ist passiert'
+    end
+```
+
+bekommt man dieses:
+
+```
+    Au weia, etwas Schlimmes ist passiert
+```
+
+Alternativ kann ein Error-Handler auch für einen Status-Code definiert werden:
+
+```ruby
+    error 403 do
+      'Zugriff verboten'
+    end
+
+    get '/geheim' do
+      403
+    end
+```
+
+Oder ein Status-Code-Bereich:
+
+```ruby
+    error 400..510 do
+      'Hallo?'
+    end
+```
+
+Sinatra setzt verschiedene `not_found`- und `error`-Handler in der
+Development-Umgebung.
+
+## Rack-Middleware
+
+Sinatra baut auf [Rack](http://rack.rubyforge.org/), einem minimalistischen
+Standard-Interface für Ruby-Webframeworks. Eines der interessantesten Features
+für Entwickler ist der Support von Middlewares, die zwischen den Server und
+die Anwendung geschaltet werden und so HTTP-Request und/oder Antwort
+überwachen und/oder manipulieren können.
+
+Sinatra macht das Erstellen von Middleware-Verkettungen mit der
+Top-Level-Methode `use` zu einem Kinderspiel:
+
+```ruby
+    require 'sinatra'
+    require 'meine_middleware'
+
+    use Rack::Lint
+    use MeineMiddleware
+
+    get '/hallo' do
+      'Hallo Welt'
+    end
+```
+
+Die Semantik von `use` entspricht der gleichnamigen Methode der
+[Rack::Builder](http://rack.rubyforge.org/doc/classes/Rack/Builder.html)-DSL
+(meist verwendet in Rackup-Dateien). Ein Beispiel dafür ist, dass die
+`use`-Methode mehrere/verschiedene Argumente und auch Blöcke entgegennimmt:
+
+```ruby
+    use Rack::Auth::Basic do |username, password|
+      username == 'admin' && password == 'geheim'
+    end
+```
+
+Rack bietet eine Vielzahl von Standard-Middlewares für Logging, Debugging,
+URL-Routing, Authentifizierung und Session-Verarbeitung. Sinatra verwendet
+viele von diesen Komponenten automatisch, abhängig von der Konfiguration. So
+muss `use` häufig nicht explizit verwendet werden.
+
+Hilfreiche Middleware gibt es z.B. hier:
+[rack](https://github.com/rack/rack/tree/master/lib/rack),
+[rack-contrib](https://github.com/rack/rack-contrib#readme), mit
+[CodeRack](http://coderack.org/) oder im [Rack
+wiki](https://github.com/rack/rack/wiki/List-of-Middleware).
+
+## Testen
+
+Sinatra-Tests können mit jedem auf Rack aufbauendem Test-Framework geschrieben
+werden. [Rack::Test](http://rdoc.info/github/brynary/rack-test/master/frames)
+wird empfohlen:
+
+```ruby
+    require 'my_sinatra_app'
+    require 'test/unit'
+    require 'rack/test'
+
+    class MyAppTest < Test::Unit::TestCase
+      include Rack::Test::Methods
+
+      def app
+        Sinatra::Application
+      end
+
+      def test_my_default
+        get '/'
+        assert_equal 'Hallo Welt!', last_response.body
+      end
+
+      def test_with_params
+        get '/meet', :name => 'Frank'
+        assert_equal 'Hallo Frank!', last_response.body
+      end
+
+      def test_with_rack_env
+        get '/', {}, 'HTTP_USER_AGENT' => 'Songbird'
+        assert_equal "Du verwendest Songbird!", last_response.body
+      end
+    end
+```
+
+## Sinatra::Base - Middleware, Bibliotheken und modulare Anwendungen
+
+Das Definieren einer Top-Level-Anwendung funktioniert gut für
+Mikro-Anwendungen, hat aber Nachteile, wenn wiederverwendbare Komponenten wie
+Middleware, Rails Metal, einfache Bibliotheken mit Server-Komponenten oder
+auch Sinatra-Erweiterungen geschrieben werden sollen.
+
+Das Top-Level geht von einer Konfiguration für eine Mikro-Anwendung aus (wie
+sie z.B. bei einer einzelnen Anwendungsdatei, `./public` und `./views` Ordner,
+Logging, Exception-Detail-Seite, usw.). Genau hier kommt `Sinatra::Base` ins
+Spiel:
+
+```ruby
+    require 'sinatra/base'
+
+    class MyApp < Sinatra::Base
+      set :sessions, true
+      set :foo, 'bar'
+
+      get '/' do
+        'Hallo Welt!'
+      end
+    end
+```
+
+Die MyApp-Klasse ist eine unabhängige Rack-Komponente, die als Middleware,
+Endpunkt oder via Rails Metal verwendet werden kann. Verwendet wird sie durch
+`use` oder `run` von einer Rackup-`config.ru`-Datei oder als Server-Komponente
+einer Bibliothek:
+
+```ruby
+    MyApp.run! :host => 'localhost', :port => 9090
+```
+
+Die Methoden der `Sinatra::Base`-Subklasse sind genau dieselben wie die der
+Top-Level-DSL. Die meisten Top-Level-Anwendungen können mit nur zwei
+Veränderungen zu `Sinatra::Base` konvertiert werden:
+
+*   Die Datei sollte `require 'sinatra/base'` anstelle von `require
+    'sinatra/base'` aufrufen, ansonsten werden alle von Sinatras DSL-Methoden
+    in den Top-Level-Namespace importiert.
+*   Alle Routen, Error-Handler, Filter und Optionen der Applikation müssen in
+    einer Subklasse von `Sinatra::Base` definiert werden.
+
+
+`Sinatra::Base` ist ein unbeschriebenes Blatt. Die meisten Optionen sind per
+Standard deaktiviert. Das betrifft auch den eingebauten Server. Siehe
+[Optionen und Konfiguration](http://sinatra.github.com/configuration.html) für
+Details über mögliche Optionen.
+
+### Modularer vs. klassischer Stil
+
+Entgegen häufiger Meinungen gibt es nichts gegen den klassischen Stil
+einzuwenden. Solange es die Applikation nicht beeinträchtigt, besteht kein
+Grund, eine modulare Applikation zu erstellen.
+
+Der größte Nachteil der klassischen Sinatra Anwendung gegenüber einer
+modularen ist die Einschränkung auf eine Sinatra Anwendung pro Ruby-Prozess.
+Sollen mehrere zum Einsatz kommen, muss auf den modularen Stil umgestiegen
+werden. Dabei ist es kein Problem klassische und modulare Anwendungen
+miteinander zu vermischen.
+
+Bei einem Umstieg, sollten einige Unterschiede in den Einstellungen beachtet
+werden:
+
+```
+    Szenario            Classic                 Modular
+    ---------------------------------------------------
+    
+    app_file            sinatra ladende Datei   Sinatra::Base subklassierende Datei
+    run                 $0 == app_file          false
+    logging             true                    false
+    method_override     true                    false
+    inline_templates    true                    false
+```
+
+### Eine modulare Applikation bereitstellen
+
+Es gibt zwei übliche Wege, eine modulare Anwendung zu starten. Zum einen über
+`run!`:
+
+```ruby
+    # mein_app.rb
+    require 'sinatra/base'
+
+    class MeinApp < Sinatra::Base
+      # ... Anwendungscode hierhin ...
+
+      # starte den Server, wenn die Ruby-Datei direkt ausgeführt wird
+      run! if app_file == $0
+    end
+```
+
+Starte mit:
+
+```
+    ruby mein_app.rb
+```
+
+Oder über eine `config.ru`-Datei, die es erlaubt, einen beliebigen
+Rack-Handler zu verwenden:
+
+```ruby
+    # config.ru
+    require './mein_app'
+    run MeineApp
+```
+
+Starte:
+
+```
+    rackup -p 4567
+```
+
+### Eine klassische Anwendung mit einer config.ru verwenden
+
+Schreibe eine Anwendungsdatei:
+
+```ruby
+    # app.rb
+    require 'sinatra'
+
+    get '/' do
+      'Hallo Welt!'
+    end
+```
+
+sowie eine dazugehörige `config.ru`-Datei:
+
+```ruby
+    require './app'
+    run Sinatra::Application
+```
+
+### Wann sollte eine config.ru-Datei verwendet werden?
+
+Anzeichen dafür, dass eine `config.ru`-Datei gebraucht wird:
+
+*   Es soll ein anderer Rack-Handler verwendet werden (Passenger, Unicorn,
+    Heroku, ...).
+*   Es gibt mehr als nur eine Subklasse von `Sinatra::Base`.
+*   Sinatra soll als Middleware verwendet werden, nicht als Endpunkt.
+
+
+**Es gibt keinen Grund, eine `config.ru`-Datei zu verwenden, nur weil eine
+Anwendung im modularen Stil betrieben werden soll. Ebenso wird keine Anwendung
+mit modularem Stil benötigt, um eine `config.ru`-Datei zu verwenden.**
+
+### Sinatra als Middleware nutzen
+
+Es ist nicht nur möglich, andere Rack-Middleware mit Sinatra zu nutzen, es
+kann außerdem jede Sinatra-Anwendung selbst als Middleware vor jeden
+beliebigen Rack-Endpunkt gehangen werden. Bei diesem Endpunkt muss es sich
+nicht um eine andere Sinatra-Anwendung handeln, es kann jede andere
+Rack-Anwendung sein (Rails/Ramaze/Camping/...):
+
+```ruby
+    require 'sinatra/base'
+
+    class LoginScreen < Sinatra::Base
+      enable :sessions
+
+      get('/login') { haml :login }
+
+      post('/login') do
+        if params[:name] == 'admin' && params[:password] == 'admin'
+          session['user_name'] = params[:name]
+        else
+          redirect '/login'
+        end
+      end
+    end
+
+    class MyApp < Sinatra::Base
+      # Middleware wird vor Filtern ausgeführt
+      use LoginScreen
+
+      before do
+        unless session['user_name']
+          halt "Zugriff verweigert, bitte <a href='/login'>einloggen</a>."
+        end
+      end
+
+      get('/') { "Hallo #{session['user_name']}." }
+    end
+```
+
+### Dynamische Applikationserstellung
+
+Manche Situationen erfordern die Erstellung neuer Applikationen zur Laufzeit,
+ohne dass sie einer Konstanten zugeordnet werden. Dies lässt sich mit
+`Sinatra.new` erreichen:
+
+```ruby
+    require 'sinatra/base'
+    my_app = Sinatra.new { get('/') { "hallo" } }
+    my_app.run!
+```
+
+Die Applikation kann mit Hilfe eines optionalen Parameters erstellt werden:
+
+```ruby
+    # config.ru
+    require 'sinatra/base'
+
+    controller = Sinatra.new do
+      enable :logging
+      helpers MyHelpers
+    end
+
+    map('/a') do
+      run Sinatra.new(controller) { get('/') { 'a' } }
+    end
+
+    map('/b') do
+      run Sinatra.new(controller) { get('/') { 'b' } }
+    end
+```
+
+Das ist besonders dann interessant, wenn Sinatra-Erweiterungen getestet werden
+oder Sinatra in einer Bibliothek Verwendung findet.
+
+Ebenso lassen sich damit hervorragend Sinatra-Middlewares erstellen:
+
+```ruby
+    require 'sinatra/base'
+
+    use Sinatra do
+      get('/') { ... }
+    end
+
+    run RailsProject::Application
+```
+
+## Geltungsbereich und Bindung
+
+Der Geltungsbereich (Scope) legt fest, welche Methoden und Variablen zur
+Verfügung stehen.
+
+### Anwendungs- oder Klassen-Scope
+
+Jede Sinatra-Anwendung entspricht einer `Sinatra::Base`-Subklasse. Falls die
+Top- Level-DSL verwendet wird (`require 'sinatra'`), handelt es sich um
+`Sinatra::Application`, andernfalls ist es jene Subklasse, die explizit
+angelegt wurde. Auf Klassenebene stehen Methoden wie `get` oder `before` zur
+Verfügung, es gibt aber keinen Zugriff auf das `request`-Object oder die
+`session`, da nur eine einzige Klasse für alle eingehenden Anfragen genutzt
+wird.
+
+Optionen, die via `set` gesetzt werden, sind Methoden auf Klassenebene:
+
+```ruby
+    class MyApp < Sinatra::Base
+      # Hey, ich bin im Anwendungsscope!
+      set :foo, 42
+      foo # => 42
+
+      get '/foo' do
+        # Hey, ich bin nicht mehr im Anwendungs-Scope!
+      end
+    end
+```
+
+Im Anwendungs-Scope befindet man sich:
+
+*   In der Anwendungs-Klasse.
+*   In Methoden, die von Erweiterungen definiert werden.
+*   Im Block, der an `helpers` übergeben wird.
+*   In Procs und Blöcken, die an `set` übergeben werden.
+*   Der an `Sinatra.new` übergebene Block
+
+
+Auf das Scope-Objekt (die Klasse) kann wie folgt zugegriffen werden:
+
+*   Über das Objekt, das an den `configure`-Block übergeben wird (`configure {
+    |c| ... }`).
+*   `settings` aus den anderen Scopes heraus.
+
+
+### Anfrage- oder Instanz-Scope
+
+Für jede eingehende Anfrage wird eine neue Instanz der Anwendungs-Klasse
+erstellt und alle Handler in diesem Scope ausgeführt. Aus diesem Scope heraus
+kann auf `request` oder `session` zugegriffen und Methoden wie `erb` oder
+`haml` aufgerufen werden. Außerdem kann mit der `settings`-Method auf den
+Anwendungs-Scope zugegriffen werden:
+
+```ruby
+    class MyApp < Sinatra::Base
+      # Hey, ich bin im Anwendungs-Scope!
+      get '/neue_route/:name' do
+        # Anfrage-Scope für '/neue_route/:name'
+        @value = 42
+
+        settings.get "/#{params[:name]}" do
+          # Anfrage-Scope für "/#{params[:name]}"
+          @value # => nil (nicht dieselbe Anfrage)
+        end
+
+        "Route definiert!"
+      end
+    end
+```
+
+Im Anfrage-Scope befindet man sich:
+
+*   In get/head/post/put/delete-Blöcken
+*   In before/after-Filtern
+*   In Helfer-Methoden
+*   In Templates
+
+
+### Delegation-Scope
+
+Vom Delegation-Scope aus werden Methoden einfach an den Klassen-Scope
+weitergeleitet. Dieser verhält sich jedoch nicht 100%ig wie der Klassen-Scope,
+da man nicht die Bindung der Klasse besitzt: Nur Methoden, die explizit als
+delegierbar markiert wurden, stehen hier zur Verfügung und es kann nicht auf
+die Variablen des Klassenscopes zugegriffen werden (mit anderen Worten: es
+gibt ein anderes `self`). Weitere Delegationen können mit
+`Sinatra::Delegator.delegate :methoden_name` hinzugefügt werden.
+
+Im Delegation-Scop befindet man sich:
+
+*   Im Top-Level, wenn `require 'sinatra'` aufgerufen wurde.
+*   In einem Objekt, das mit dem `Sinatra::Delegator`-Mixin erweitert wurde.
+
+
+Schau am besten im Code nach: Hier ist [Sinatra::Delegator
+mixin](http://github.com/sinatra/sinatra/blob/master/lib/sinatra/base.rb#L1064
+) definiert und wird in den [globalen Namespace
+eingebunden](http://github.com/sinatra/sinatra/blob/master/lib/sinatra/main.rb
+
+## Kommandozeile
+
+Sinatra-Anwendungen können direkt von der Kommandozeile aus gestartet werden:
+
+```
+    ruby myapp.rb [-h] [-x] [-e ENVIRONMENT] [-p PORT] [-h HOST] [-s HANDLER]
+```
+
+Die Optionen sind:
+
+```
+    -h # Hilfe
+    -p # Port setzen (Standard ist 4567)
+    -h # Host setzen (Standard ist 0.0.0.0)
+    -e # Umgebung setzen (Standard ist development)
+    -s # Rack-Server/Handler setzen (Standard ist thin)
+    -x # Mutex-Lock einschalten (Standard ist off)
+```
+
+## Systemanforderungen
+
+Die folgenden Versionen werden offiziell unterstützt:
+
+<dl>
+  <dt>Ruby 1.8.7</dt>
+  <dd>1.8.7 wird vollständig unterstützt, aber solange nichts dagegen spricht,
+  wird ein Update auf 1.9.2 oder ein Umstieg auf JRuby/Rubinius empfohlen.
+  Unterstützung für 1.8.7 wird es mindestens bis Sinatra 2.0 und Ruby 2.0
+  geben, es sei denn, dass der unwahrscheinliche Fall eintritt und 1.8.8
+  rauskommt. Doch selbst dann ist es eher wahrscheinlich, dass 1.8.7 weiterhin
+  unterstützt wird. <b>Ruby 1.8.6 wird nicht mehr unterstützt.</b> Soll Sinatra
+  unter 1.8.6 eingesetzt werden, muss Sinatra 1.2 verwendet werden, dass noch
+  bis zum Release von Sinatra 1.4.0 fortgeführt wird.</dd>
+
+  <dt>Ruby 1.9.2</dt>
+  <dd>1.9.2 wird voll unterstützt und empfohlen. Version 1.9.2p0 sollte nicht
+  verwendet werden, da unter Sinatra immer wieder Segfaults auftreten.
+  Unterstützung wird es mindestens bis zum Release von Ruby 1.9.4/2.0 geben und
+  das letzte Sinatra Release für 1.9 wird so lange unterstützt, wie das Ruby
+  Core-Team 1.9 pflegt.</dd>
+
+  <dt>Ruby 1.9.3</dt>
+  <dd>1.9.3 wird vollständig unterstützt und empfohlen. Achtung, bei einem
+  Wechsel zu 1.9.3 werden alle Sessions ungültig.</dd>
+
+  <dt>Rubinius</dt>
+  <dd>Rubinius (rbx >= 1.2.4) wird offiziell unter Einbezug aller Templates
+  unterstützt. Die kommende 2.0 Version wird ebenfalls unterstützt, samt 1.9
+  Modus.</dd>
+
+  <dt>JRuby</dt>
+  <dd>JRuby wird offiziell unterstützt (JRuby >= 1.6.7). Probleme mit
+  Template- Bibliotheken Dritter sind nicht bekannt. Falls JRuby zum Einsatz
+  kommt, sollte aber darauf geachtet werden, dass ein JRuby-Rack-Handler zum
+  Einsatz kommt – die Thin und Mongrel Web-Server werden bisher nicht
+  unterstütz. JRubys Unterstützung für C-Erweiterungen sind zur Zeit ebenfalls
+  experimenteller Natur, betrifft im Moment aber nur die RDiscount, Redcarpet,
+  RedCloth und Yajl Templates.</dd>
+</dl>
+
+Weiterhin werden wir die kommende Ruby-Versionen im Auge behalten.
+
+Die nachfolgend aufgeführten Ruby-Implementierungen werden offiziell nicht von
+Sinatra unterstützt, funktionieren aber normalerweise:
+
+*   Ruby Enterprise Edition
+*   Ältere Versionen von JRuby und Rubinius
+*   MacRuby, Maglev, IronRuby
+*   Ruby 1.9.0 und 1.9.1 (wird jedoch nicht empfohlen, s.o.)
+
+
+Nicht offiziell unterstützt bedeutet, dass wenn Sachen nicht funktionieren,
+wir davon ausgehen, dass es nicht an Sinatra sondern an der jeweiligen
+Implentierung liegt.
+
+Im Rahmen unserer CI (Kontinuierlichen Integration) wird bereits ruby-head
+(das kommende Ruby 2.0.0) und 1.9.4 mit eingebunden. Da noch alles im Fluss
+ist, kann zur Zeit für nichts garantiert werden. Es kann aber erwartet werden,
+dass Ruby 2.0.0p0 und 1.9.4p0 von Sinatra unterstützt werden wird.
+
+Sinatra sollte auf jedem Betriebssystem laufen, dass den gewählten Ruby-
+Interpreter unterstützt.
+
+Sinatra wird aktuell nicht unter Cardinal, SmallRuby, BleuRuby oder
+irgendeiner  Version von Ruby vor 1.8.7 laufen.
+
+## Der neuste Stand (The Bleeding Edge)
+
+Um auf dem neusten Stand zu bleiben, kann der Master-Branch verwendet werden.
+Er sollte recht stabil sein. Ebenso gibt es von Zeit zu Zeit prerelease Gems,
+die so installiert werden:
+
+```
+    gem install sinatra --pre
+```
+
+### Mit Bundler
+
+Wenn die Applikation mit der neuesten Version von Sinatra und
+[Bundler](http://gembundler.com/) genutzt werden soll, empfehlen wir den
+nachfolgenden Weg.
+
+Soweit Bundler noch nicht installiert ist:
+
+```
+    gem install bundler
+```
+
+Anschließend wird eine `Gemfile`-Datei im Projektverzeichnis mit folgendem
+Inhalt erstellt:
+
+```ruby
+    source :rubygems
+    gem 'sinatra', :git => "git://github.com/sinatra/sinatra.git"
+
+    # evtl. andere Abhängigkeiten
+    gem 'haml'                    # z.B. wenn du Haml verwendest...
+    gem 'activerecord', '~> 3.0'  # ...oder ActiveRecord 3.x
+```
+
+Beachte: Hier sollten alle Abhängigkeiten eingetragen werden. Sinatras eigene,
+direkte Abhängigkeiten (Tilt und Rack) werden von Bundler automatisch aus dem
+Gemfile von Sinatra hinzugefügt.
+
+Jetzt kannst du deine Applikation starten:
+
+```
+    bundle exec ruby myapp.rb
+```
+
+### Eigenes Repository
+Um auf dem neuesten Stand von Sinatras Code zu sein, kann eine lokale Kopie
+angelegt werden. Gestartet wird in der Anwendung mit dem `sinatra/lib`- Ordner
+im `LOAD_PATH`:
+
+```
+    cd myapp
+    git clone git://github.com/sinatra/sinatra.git
+    ruby -Isinatra/lib myapp.rb
+```
+
+Alternativ kann der `sinatra/lib`-Ordner zum `LOAD_PATH` in der Anwendung
+hinzugefügt werden:
+
+```ruby
+    $LOAD_PATH.unshift File.dirname(__FILE__) + '/sinatra/lib'
+    require 'rubygems'
+    require 'sinatra'
+
+    get '/ueber' do
+      "Ich laufe auf Version " + Sinatra::VERSION
+    end
+```
+
+Um Sinatra-Code von Zeit zu Zeit zu aktualisieren:
+
+```
+    cd myproject/sinatra
+    git pull
+```
+
+### Gem erstellen
+
+Aus der eigenen lokalen Kopie kann nun auch ein globales Gem gebaut werden:
+
+```
+    git clone git://github.com/sinatra/sinatra.git
+    cd sinatra
+    rake sinatra.gemspec
+    rake install
+```
+
+Falls Gems als Root installiert werden sollen, sollte die letzte Zeile
+folgendermaßen lauten:
+
+```
+    sudo rake install
+```
+
+## Versions-Verfahren
+
+Sinatra folgt dem sogenannten [Semantic Versioning](http://semver.org/), d.h.
+SemVer und SemVerTag.
+
+## Mehr
+
+*   [Projekt-Website](http://sinatra.github.com/) - Ergänzende Dokumentation,
+    News und Links zu anderen Ressourcen.
+*   [Mitmachen](http://sinatra.github.com/contributing.html) - Einen Fehler
+    gefunden? Brauchst du Hilfe? Hast du einen Patch?
+*   [Issue-Tracker](http://github.com/sinatra/sinatra/issues)
+*   [Twitter](http://twitter.com/sinatra)
+*   [Mailing-Liste](http://groups.google.com/group/sinatrarb)
+*   [ #sinatra](irc://chat.freenode.net/#sinatra) auf http://freenode.net
+*   [Sinatra Book](http://sinatra-book.gittr.com) Kochbuch Tutorial
+*   [Sinatra Recipes](http://recipes.sinatrarb.com/) Sinatra-Rezepte aus der
+    Community
+*   API Dokumentation für die [aktuelle
+    Version](http://rubydoc.info/gems/sinatra) oder für
+    [HEAD](http://rubydoc.info/github/sinatra/sinatra) auf http://rubydoc.info
+*   [CI Server](http://travis-ci.org/sinatra/sinatra)