logstash-filter-cache-redis 0.1.0

data/vendor/bundle/jruby/1.9/gems/sinatra-1.4.8/CONTRIBUTING.md

@@ -0,0 +1,100 @@
+# Contribute
+
+Want to show Sinatra some love? Help out by contributing!
+
+## Found a bug?
+
+Log it in our [issue tracker][ghi] or send a note to the [mailing list][ml].
+Be sure to include all relevant information, like the versions of Sinatra and
+Ruby you're using. A [gist](http://gist.github.com/) of the code that caused
+the issue as well as any error messages are also very helpful.
+
+## Need help?
+
+The [Sinatra mailing list][ml] has over 900 subscribers, many of which are happy
+to help out newbies or talk about potential feature additions. You can also
+drop by the [#sinatra](irc://chat.freenode.net/#sinatra) channel on
+[irc.freenode.net](http://freenode.net).
+
+## Have a patch?
+
+Bugs and feature requests that include patches are much more likely to
+get attention. Here are some guidelines that will help ensure your patch
+can be applied as quickly as possible:
+
+1. **Use [Git](http://git-scm.com) and [GitHub](http://github.com):**
+   The easiest way to get setup is to fork the
+   [sinatra/sinatra repo](http://github.com/sinatra/sinatra/).
+   Or, the [sinatra.github.com repo](http://github.com/sinatra/sinatra.github.com/),
+   if the patch is doc related.
+
+2. **Write unit tests:** If you add or modify functionality, it must
+   include unit tests. If you don't write tests, we have to, and this
+   can hold up acceptance of the patch.
+
+3. **Mind the `README`:** If the patch adds or modifies a major feature,
+   modify the `README.md` file to reflect that. Again, if you don't
+   update the `README`, we have to, and this holds up acceptance.
+
+4. **Update the change log (`CHANGELOG.md`):** The change log helps give an
+   overview of the changes that go into each release, and gives credit
+   where credit is due. We make sure that the change log is up to date
+   before each release, and we always appreciate it when people make
+   it easier to get the release out the door.
+
+5. **Push it:** Once you're ready, push your changes to a topic branch
+   and add a note to the ticket with the URL to your branch. Or, say
+   something like, "you can find the patch on johndoe/foobranch". We also
+   gladly accept GitHub [pull requests](http://help.github.com/pull-requests/).
+
+__NOTE:__ _We will take whatever we can get._ If you prefer to attach diffs in
+emails to the mailing list, that's fine; but do know that _someone_ will need
+to take the diff through the process described above and this can hold things
+up considerably.
+
+## Want to write docs?
+
+The process for contributing to Sinatra's website, documentation or the book
+is the same as contributing code. We use Git for versions control and GitHub to
+track patch requests.
+
+* [The sinatra.github.com repo](http://github.com/sinatra/sinatra.github.com/)
+  is where the website sources are managed. There are almost always people in
+  `#sinatra` that are happy to discuss, apply, and publish website patches.
+
+* [The Book](http://sinatra-book.gittr.com/) has its own [Git
+  repository](http://github.com/sinatra/sinatra-book/) and build process but is
+  managed the same as the website and project codebase.
+
+* [Sinatra Recipes](http://recipes.sinatrarb.com/) is a community
+  project where anyone is free to contribute ideas, recipes and tutorials. Which
+  also has its own [Git repository](http://github.com/sinatra/sinatra-recipes).
+
+* [The Introduction](http://www.sinatrarb.com/intro.html) is generated from
+  Sinatra's [README file](http://github.com/sinatra/sinatra/blob/master/README.md).
+
+* If you want to help translating the documentation, the README is already
+  available in
+  [Japanese](http://github.com/sinatra/sinatra/blob/master/README.ja.md),
+  [German](http://github.com/sinatra/sinatra/blob/master/README.de.md),
+  [Chinese](https://github.com/sinatra/sinatra/blob/master/README.zh.md),
+  [Russian](https://github.com/sinatra/sinatra/blob/master/README.ru.md),
+  [European](https://github.com/sinatra/sinatra/blob/master/README.pt-pt.md) and
+  [Brazilian](https://github.com/sinatra/sinatra/blob/master/README.pt-br.md)
+  Portuguese,
+  [French](https://github.com/sinatra/sinatra/blob/master/README.fr.md),
+  [Spanish](https://github.com/sinatra/sinatra/blob/master/README.es.md),
+  [Korean](https://github.com/sinatra/sinatra/blob/master/README.ko.md), and
+  [Hungarian](https://github.com/sinatra/sinatra/blob/master/README.hu.md).
+  The translations tend to fall behind the English version. Translations into
+  other languages would also be appreciated.
+
+## Looking for something to do?
+
+If you'd like to help out but aren't sure how, pick something that looks
+interesting from the [issues][ghi] list and hack on. Make sure to leave a
+comment on the ticket noting that you're investigating (a simple "Taking…" is
+fine).
+
+[ghi]: http://github.com/sinatra/sinatra/issues
+[ml]: http://groups.google.com/group/sinatrarb/topics "Sinatra Mailing List"

data/vendor/bundle/jruby/1.9/gems/sinatra-1.4.8/Gemfile

@@ -0,0 +1,79 @@
+# Why use bundler?
+# Well, not all development dependencies install on all rubies. Moreover, `gem
+# install sinatra --development` doesn't work, as it will also try to install
+# development dependencies of our dependencies, and those are not conflict free.
+# So, here we are, `bundle install`.
+#
+# 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']
+gemspec
+
+gem 'rake', '~> 10.0'
+gem 'rack-test', '>= 0.6.2'
+gem "minitest", "~> 5.0"
+
+if RUBY_ENGINE == 'jruby'
+  gem 'nokogiri', '!= 1.5.0'
+  gem 'jruby-openssl'
+  gem 'trinidad'
+end
+
+if RUBY_VERSION < '1.9.3'
+  gem 'activesupport', '~> 3.2'
+  gem 'i18n', '~> 0.6.0'
+else
+  gem 'activesupport', '~> 4.2'
+end
+
+if RUBY_ENGINE == "ruby"
+  if RUBY_VERSION > '1.9.2'
+    gem 'less', '~> 2.0'
+    gem 'therubyracer'
+    gem 'redcarpet'
+    gem 'wlang', '>= 2.0.1'
+    gem 'bluecloth'
+    gem 'rdiscount'
+    gem 'RedCloth'
+    gem 'puma'
+    gem 'net-http-server'
+    gem 'yajl-ruby'
+    gem 'thin'
+    gem 'slim', '~> 2.0'
+    gem 'coffee-script', '>= 2.0'
+    gem 'rdoc'
+    gem 'kramdown'
+    gem 'maruku'
+    gem 'creole'
+    gem 'wikicloth'
+    gem 'markaby'
+    gem 'radius'
+    gem 'asciidoctor'
+    gem 'liquid', '~> 3.0'
+    gem 'stylus'
+    gem 'rabl'
+    gem 'builder'
+    gem 'erubis'
+    gem 'haml', '>= 3.0'
+    gem 'sass'
+    
+    if RUBY_VERSION < '2.1.0'
+      gem 'nokogiri', '~> 1.6.8'
+    else
+      gem 'nokogiri', '~> 1.7.0'
+    end
+  else
+    gem 'nokogiri', '~> 1.5.11'
+  end
+end
+
+if RUBY_ENGINE == "rbx"
+  gem 'json'
+  gem 'rubysl'
+  gem 'rubysl-test-unit'
+end
+
+platforms :ruby_18, :jruby do
+  gem 'json', '~> 1.8' unless RUBY_VERSION > '1.9' # is there a jruby but 1.8 only selector?
+end

data/vendor/bundle/jruby/1.9/gems/sinatra-1.4.8/LICENSE

@@ -0,0 +1,23 @@
+Copyright (c) 2007, 2008, 2009 Blake Mizerany
+Copyright (c) 2010, 2011, 2012, 2013, 2014, 2015, 2016 Konstantin Haase
+
+Permission is hereby granted, free of charge, to any person
+obtaining a copy of this software and associated documentation
+files (the "Software"), to deal in the Software without
+restriction, including without limitation the rights to use,
+copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following
+conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+OTHER DEALINGS IN THE SOFTWARE.

data/vendor/bundle/jruby/1.9/gems/sinatra-1.4.8/README.de.md

@@ -0,0 +1,3031 @@
+# Sinatra
+
+*Wichtig: Dieses Dokument ist eine Übersetzung aus dem Englischen und unter
+Umständen nicht auf dem aktuellen Stand (aktuell Sinatra 1.4.5).*
+
+Sinatra ist eine
+[DSL](https://de.wikipedia.org/wiki/Domänenspezifische_Sprache), die das
+schnelle Erstellen von Webanwendungen in Ruby mit minimalem Aufwand
+ermöglicht:
+
+Sinatra via `rubygems` installieren:
+
+```shell
+gem install sinatra
+```
+
+Eine Datei mit dem Namen `myapp.rb` erstellen:
+
+```ruby
+require 'sinatra'
+get '/' do
+  'Hallo Welt!'
+end
+```
+
+und im gleichen Verzeichnis ausführen:
+
+```shell
+ruby myapp.rb
+```
+
+Die Seite kann nun unter [http://localhost:4567](http://localhost:4567)
+aufgerufen werden.
+
+## Inhalt
+
+* [Sinatra](#sinatra)
+    * [Routen](#routen)
+        * [Bedingungen](#bedingungen)
+        * [Rückgabewerte](#rckgabewerte)
+        * [Eigene Routen-Muster](#eigene-routen-muster)
+    * [Statische Dateien](#statische-dateien)
+    * [Views/Templates](#viewstemplates)
+        * [Direkte Templates](#direkte-templates)
+        * [Verfügbare Templatesprachen](#verfgbare-templatesprachen)
+            * [Haml Templates](#haml-templates)
+            * [Erb Templates](#erb-templates)
+            * [Builder Templates](#builder-templates)
+            * [Nokogiri Templates](#nokogiri-templates)
+            * [Sass Templates](#sass-templates)
+            * [SCSS Templates](#scss-templates)
+            * [Less Templates](#less-templates)
+            * [Liquid Templates](#liquid-templates)
+            * [Markdown Templates](#markdown-templates)
+            * [Textile Templates](#textile-templates)
+            * [RDoc Templates](#rdoc-templates)
+            * [AsciiDoc Templates](#asciidoc-templates)
+            * [Radius Templates](#radius-templates)
+            * [Markaby Templates](#markaby-templates)
+            * [RABL Templates](#rabl-templates)
+            * [Slim Templates](#slim-templates)
+            * [Creole Templates](#creole-templates)
+            * [MediaWiki Templates](#mediawiki-templates)
+            * [CoffeeScript Templates](#coffeescript-templates)
+            * [Stylus Templates](#stylus-templates)
+            * [Yajl Templates](#yajl-templates)
+            * [WLang Templates](#wlang-templates)
+        * [Auf Variablen in Templates zugreifen](#auf-variablen-in-templates-zugreifen)
+        * [Templates mit `yield` und verschachtelte Layouts](#templates-mit-yield-und-verschachtelte-layouts)
+        * [Inline-Templates](#inline-templates)
+        * [Benannte Templates](#benannte-templates)
+        * [Dateiendungen zuordnen](#dateiendungen-zuordnen)
+        * [Eine eigene Template-Engine hinzufügen](#eine-eigene-template-engine-hinzufgen)
+        * [Eigene Methoden zum Aufsuchen von Templates verwenden](#eigene-methoden-zum-aufsuchen-von-templates-verwenden)
+    * [Filter](#filter)
+    * [Helfer](#helfer)
+        * [Sessions verwenden](#sessions-verwenden)
+        * [Anhalten](#anhalten)
+        * [Weiterspringen](#weiterspringen)
+        * [Eine andere Route ansteuern](#eine-andere-route-ansteuern)
+        * [Body, Status-Code und Header setzen](#body-status-code-und-header-setzen)
+        * [Response-Streams](#response-streams)
+        * [Logger](#logger)
+        * [Mime-Types](#mime-types)
+        * [URLs generieren](#urls-generieren)
+        * [Browser-Umleitung](#browser-umleitung)
+        * [Cache einsetzen](#cache-einsetzen)
+        * [Dateien versenden](#dateien-versenden)
+        * [Das Request-Objekt](#das-request-objekt)
+        * [Anhänge](#anhnge)
+        * [Umgang mit Datum und Zeit](#umgang-mit-datum-und-zeit)
+        * [Nachschlagen von Template-Dateien](#nachschlagen-von-template-dateien)
+        * [Konfiguration](#konfiguration)
+            * [Einstellung des Angriffsschutzes](#einstellung-des-angriffsschutzes)
+            * [Mögliche Einstellungen](#mgliche-einstellungen)
+    * [Umgebungen](#umgebungen)
+    * [Fehlerbehandlung](#fehlerbehandlung)
+        * [Nicht gefunden](#nicht-gefunden)
+        * [Fehler](#fehler)
+    * [Rack-Middleware](#rack-middleware)
+    * [Testen](#testen)
+    * [Sinatra::Base - Middleware, Bibliotheken und modulare Anwendungen](#sinatrabase---middleware-bibliotheken-und-modulare-anwendungen)
+        * [Modularer vs. klassischer Stil](#modularer-vs-klassischer-stil)
+        * [Eine modulare Applikation bereitstellen](#eine-modulare-applikation-bereitstellen)
+        * [Eine klassische Anwendung mit einer config.ru verwenden](#eine-klassische-anwendung-mit-einer-configru-verwenden)
+        * [Wann sollte eine config.ru-Datei verwendet werden?](#wann-sollte-eine-configru-datei-verwendet-werden)
+        * [Sinatra als Middleware nutzen](#sinatra-als-middleware-nutzen)
+        * [Dynamische Applikationserstellung](#dynamische-applikationserstellung)
+    * [Geltungsbereich und Bindung](#geltungsbereich-und-bindung)
+        * [Anwendungs- oder Klassen-Scope](#anwendungs--oder-klassen-scope)
+        * [Anfrage- oder Instanz-Scope](#anfrage--oder-instanz-scope)
+        * [Delegation-Scope](#delegation-scope)
+    * [Kommandozeile](#kommandozeile)
+      * [Multi-Threading](#multi-threading)
+    * [Systemanforderungen](#systemanforderungen)
+    * [Der neuste Stand (The Bleeding Edge)](#der-neuste-stand-the-bleeding-edge)
+        * [Mit Bundler](#mit-bundler)
+        * [Eigenes Repository](#eigenes-repository)
+        * [Gem erstellen](#gem-erstellen)
+    * [Versions-Verfahren](#versions-verfahren)
+    * [Mehr](#mehr)
+
+## 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
+
+link '/' do
+  .. verbinde etwas ..
+end
+
+unlink '/' do
+  .. trenne etwas ..
+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 dann 'foo' oder 'bar'
+  "Hallo #{params['name']}!"
+end
+```
+
+Man kann auf diese auch mit Block-Parametern zugreifen:
+
+```ruby
+get '/hallo/:name' do |n|
+  # n entspricht hier params['name']
+  "Hallo #{n}!"
+end
+```
+
+Routen-Muster können auch mit sog. Splat- oder Wildcard-Parametern über das
+`params['splat']`-Array angesprochen werden:
+
+```ruby
+get '/sag/*/zu/*' do
+  # passt z.B. 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 /\A\/hallo\/([\w]+)\z/ 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
+```
+
+Routen können auch den query-Parameter verwenden:
+
+```ruby
+get '/posts' do
+  # matches "GET /posts?title=foo&author=bar"
+  title = params['title']
+  author = params['author']
+  # uses title and author variables; query is optional to the /posts route
+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 geknüpft werden, die erfüllt
+sein müssen, damit der Block ausgeführt wird. Möglich wäre etwa eine
+Einschränkung des User-Agents über die interne Bedingung `:agent`:
+
+```ruby
+get '/foo', :agent => /Songbird (\d\.\d)[\d\/]*?/ do
+  "Du verwendest Songbird Version #{params['agent'][0]}"
+end
+```
+
+Wird Songbird als Browser nicht verwendet, springt Sinatra zur nächsten Route:
+
+```ruby
+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
+```
+`provides` durchsucht den Accept-Header der Anfrage
+
+Eigene Bedingungen können relativ einfach hinzugefügt werden:
+
+```ruby
+set(:wahrscheinlichkeit) { |value| condition { rand <= value } }
+
+get '/auto_gewinnen', :wahrscheinlichkeit => 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 im `./public`-Ordner erwartet. 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 Einstellungen, die für alle Routen gelten,
+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 an das Dokument weitergegeben werden.
+    Praktisch für Partials:
+
+    <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 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, dann legt es fest,
+    welches Template als Layout verwendet wird:
+
+    <tt>erb :index, :layout => !request.xhr?</tt></dd>
+
+  <dt>content_type</dt>
+  <dd>Content-Typ 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:
+
+    <tt>set :rdoc, :layout_engine => :erb</tt></dd>
+
+  <dt>layout_options</dt>
+  <dd>Besondere Einstellungen, die nur für das Rendering verwendet werden:
+
+    <tt>set :rdoc, :layout_options => { :views => 'views/layouts' }</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.
+
+### Direkte Templates
+
+```ruby
+get '/' do
+  haml '%div.title Hallo Welt'
+end
+```
+
+Hier wird der String direkt gerendert.
+
+### 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="https://github.com/jimweirich/builder">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://www.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://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://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/davidfstr/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.gettalong.org/" title="kramdown">kramdown</a> oder
+        <a href="https://github.com/bhollis/maruku" 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.sourceforge.net/">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.
+
+#### AsciiDoc Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="http://asciidoctor.org/" title="Asciidoctor">Asciidoctor</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterungen</td>
+    <td><tt>.asciidoc</tt>, <tt>.adoc</tt> und <tt>.ad</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>asciidoc :README, :layout_engine => :erb</tt></td>
+  </tr>
+</table>
+
+Da man aus dem AsciiDoc-Template heraus keine Ruby-Methoden aufrufen kann
+(ausgenommen `yield`), wird man üblicherweise locals verwenden wollen, mit
+denen man Variablen weitergibt.
+
+#### Radius Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="https://github.com/jlong/radius">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.io/">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.
+
+#### MediaWiki Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="https://github.com/nricciar/wikicloth" title="WikiCloth">WikiCloth</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterungen</td>
+    <td><tt>.mediawiki</tt> und <tt>.mw</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>mediawiki :wiki, :layout_engine => :erb</tt></td>
+  </tr>
+</table>
+
+Da man aus dem Mediawiki-Template heraus keine Ruby-Methoden aufrufen und auch
+keine locals verwenden kann, wird man Mediawiki üblicherweise in Kombination mit
+anderen Renderern verwenden wollen:
+
+```ruby
+erb :overview, :locals => { :text => mediawiki(:introduction) }
+```
+
+Beachte: Man kann die `mediawiki`-Methode auch aus anderen Templates
+heraus aufrufen:
+
+```ruby
+%h1 Grüße von Haml!
+%p= mediawiki(:greetings)
+```
+
+Da man Ruby nicht von MediaWiki heraus aufrufen kann, können auch Layouts nicht
+in MediaWiki 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>
+
+#### Stylus Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td>
+      <a href="https://github.com/forgecrafted/ruby-stylus" title="Ruby Stylus">
+        Stylus
+      </a> und eine Möglichkeit
+      <a href="https://github.com/sstephenson/execjs/blob/master/README.md#readme" title="ExecJS">
+        JavaScript auszuführen
+      </a>.
+    </td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.styl</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td><tt>stylus :index</tt></td>
+  </tr>
+</table>
+
+Um Stylus-Templates ausführen zu können, müssen `stylus` und `stylus/tilt`
+zuerst geladen werden:
+
+```ruby
+require 'sinatra'
+require 'stylus'
+require 'stylus/tilt'
+
+get '/' do
+  stylus :example
+end
+```
+
+#### Yajl Templates
+
+<table>
+  <tr>
+    <td>Abhängigkeit</td>
+    <td><a href="https://github.com/brianmario/yajl-ruby" title="yajl-ruby">yajl-ruby</a></td>
+  </tr>
+  <tr>
+    <td>Dateierweiterung</td>
+    <td><tt>.yajl</tt></td>
+  </tr>
+  <tr>
+    <td>Beispiel</td>
+    <td>
+      <tt>
+        yajl :index,
+             :locals => { :key => 'qux' },
+             :callback => 'present',
+             :variable => 'resource'
+      </tt>
+    </td>
+  </tr>
+</table>
+
+Die Template-Quelle wird als Ruby-String evaluiert. Die daraus resultierende
+json Variable wird mit Hilfe von `#to_json` umgewandelt:
+
+```ruby
+json = { :foo => 'bar' }
+json[:baz] = key
+```
+
+Die `:callback` und `:variable` Optionen können mit dem gerenderten Objekt
+verwendet werden:
+
+```javascript
+var resource = {"foo":"bar","baz":"qux"};
+present(resource);
+```
+
+#### 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.
+
+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.
+
+### Templates mit `yield` und verschachtelte Layouts
+
+Ein Layout ist üblicherweise ein Template, das ein `yield` aufruft. Ein solches
+Template kann entweder wie oben beschrieben über die `:template` Option
+verwendet werden oder mit einem Block gerendert werden:
+
+```ruby
+erb :post, :layout => false do
+  erb :index
+end
+```
+
+Dieser Code entspricht weitestgehend `erb :index, :layout => :post`.
+
+Blöcke an Render-Methoden weiterzugeben ist besonders bei verschachtelten
+Layouts hilfreich:
+
+```ruby
+erb :main_layout, :layout => false do
+  erb :admin_layout do
+    erb :user
+  end
+end
+```
+
+Der gleiche Effekt kann auch mit weniger Code erreicht werden:
+
+```ruby
+erb :admin_layout, :layout => :main_layout do
+  erb :user
+end
+```
+
+Zur Zeit nehmen folgende Renderer Blöcke an: `erb`, `haml`, `liquid`, `slim `
+und `wlang`.
+
+Das gleich gilt auch für die allgemeine `render` Methode.
+
+### 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?
+  # !request.xhr? prüft, ob es sich um einen asynchronen Request handelt.
+  # wenn nicht, dann verwende ein Layout (negiert durch !)
+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.
+
+### Eigene Methoden zum Aufsuchen von Templates verwenden
+
+Um einen eigenen Mechanismus zum Aufsuchen von Templates zu
+implementieren, muss `#find_template` definiert werden:
+
+```ruby
+configure do
+  set :views [ './views/a', './views/b' ]
+end
+
+def find_template(views, name, engine, &block)
+  Array(views).each do |v|
+    super(v, name, engine, &block)
+  end
+end
+```
+
+## 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, das 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_geheimes_Gegeimnis'
+```
+
+Zur weiteren Konfiguration kann man einen Hash mit Optionen in den `sessions`
+Einstellungen ablegen.
+
+```ruby
+set :sessions, :domain => 'foo.com'
+```
+
+Um eine Session mit anderen Apps und zwischen verschiedenen Subdomains
+von foo.com zu teilen, wird ein *.* der Domain vorangestellt:
+
+```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 mit 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
+
+Wenn nicht zu einer anderen Route gesprungen werden soll, sondern nur das
+Ergebnis einer anderen Route gefordert wird, kann `call` für einen internen
+Request verwendet werden:
+
+```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.
+
+### 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 anderer Stelle während der Ausführung gesetzt werden soll.
+Dafür kann man die Helfer-Methode `body` einsetzen. Ist sie gesetzt, kann sie zu
+einem späteren Zeitpunkt aufgerufen werden:
+
+```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](https://w3c.github.io/eventsource/), die als Basis für
+[WebSockets](https://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 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
+# Durchgehende Anfrage (long polling)
+
+set :server, :thin
+connections = []
+
+get '/subscribe' do
+  # Client-Registrierung beim Server, damit Events mitgeteilt werden können
+  stream(:keep_open) do |out|
+    connections << out
+    # tote Verbindungen entfernen
+    connections.reject!(&:closed?)
+  end
+end
+
+post '/:message' do
+  connections.each do |out|
+    # Den Client über eine neue Nachricht in Kenntnis setzen
+    # notify client that a new message has arrived
+    out << params['message'] << "\n"
+
+    # Den Client zur erneuten Verbindung auffordern
+    out.close
+  end
+
+  # Rückmeldung
+  "Mitteiling erhalten"
+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://www.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](https://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
+
+Um den Inhalt einer Datei als Response zurückzugeben, 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_param"]  # Wert von einem Parameter; [] ist die Kurzform für den params Hash
+  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/sinatra/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ögliche 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_charset</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_charset << "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: <tt>0.0.0.0</tt>
+  <em>oder</em> <tt>localhost</tt>). 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. Die Reihenfolge gibt die Priorität vor, die Voreinstellung hängt von
+  der verwendenten Ruby Implementierung ab.</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>threaded</dt>
+  <dd>Wird es auf <tt>true</tt> gesetzt, wird Thin aufgefordert
+  <tt>EventMachine.defer</tt> zur Verarbeitung des Requests einzusetzen.</dd>
+
+  <dt>traps</dt>
+  <dd>Einstellung, Sinatra System signalen umgehen soll.</dd>
+
+  <dt>views</dt>
+  <dd>Verzeichnis der Views. Leitet sich von der <tt>app_file</tt> Einstellung
+  ab, wenn nicht gesetzt.</dd>
+
+  <dt>x_cascade</dt>
+  <dd>Einstellung, ob der X-Cascade Header bei fehlender Route gesetzt wird oder
+  nicht. Standardeinstellung ist <tt>true</tt>.</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:
+
+```shell
+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. In der
+`development`-Umgebung wird es nur dann funktionieren, wenn die
+`:show_exceptions`-Option auf `:after_handler` eingestellt wurde:
+
+```ruby
+set :show_exceptions, :after_handler
+```
+
+Die Exception kann über die `sinatra.error`-Rack-Variable angesprochen werden:
+
+```ruby
+error do
+  'Entschuldige, es gab einen hässlichen Fehler - ' + env['sinatra.error'].message
+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:
+
+```shell
+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 ein, um hilfreiche Debugging Informationen und Stack Traces
+anzuzeigen.
+
+## Rack-Middleware
+
+Sinatra baut auf [Rack](http://rack.github.io/), 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://www.rubydoc.info/github/rack/rack/master/Rack/Builder)-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),
+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://www.rubydoc.info/github/brynary/rack-test/master/frames)
+wird empfohlen:
+
+```ruby
+require 'my_sinatra_app'
+require 'minitest/autorun'
+require 'rack/test'
+
+class MyAppTest < Minitest::Test
+  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
+```
+
+Hinweis: Wird Sinatra modular verwendet, muss <tt>Sinatra::Application</tt> mit
+dem Namen der Applikations-Klasse ersetzt werden.
+
+## 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://www.sinatrarb.com/configuration.html) für
+Details über mögliche Optionen.
+
+Damit eine App sich ähnlich wie eine klassische App verhält, kann man
+auch eine Subclass von `Sinatra::Application` erstellen:
+
+```ruby
+require 'sinatra/base'
+
+class MyApp < Sinatra::Application
+  get '/' do
+    'Hello world!'
+  end
+end
+```
+
+### 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:
+
+<table>
+  <tr>
+    <th>Szenario</th>
+    <th>Classic</th>
+    <th>Modular</th>
+    <th>Modular</th>
+  </tr>
+
+  <tr>
+    <td>app_file</td>
+    <td>Sinatra ladende Datei</td>
+    <td>Sinatra::Base subklassierende Datei</td>
+    <td>Sinatra::Application subklassierende Datei</td>
+  </tr>
+
+  <tr>
+    <td>run</td>
+    <td>$0 == app_file</td>
+    <td>false</td>
+    <td>false</td>
+  </tr>
+
+  <tr>
+    <td>logging</td>
+    <td>true</td>
+    <td>false</td>
+    <td>true</td>
+  </tr>
+
+  <tr>
+    <td>method_override</td>
+    <td>true</td>
+    <td>false</td>
+    <td>true</td>
+  </tr>
+
+  <tr>
+    <td>inline_templates</td>
+    <td>true</td>
+    <td>false</td>
+    <td>true</td>
+  </tr>
+
+  <tr>
+    <td>static</td>
+    <td>true</td>
+    <td>File.exist?(public_folder)</td>
+    <td>true</td>
+  </tr>
+</table>
+
+### 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:
+
+```shell
+ruby mein_app.rb
+```
+
+Oder über eine `config.ru`-Datei, die es erlaubt, einen beliebigen
+Rack-Handler zu verwenden:
+
+```ruby
+# config.ru (mit rackup starten)
+require './mein_app'
+run MeineApp
+```
+
+Starte:
+
+```shell
+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, options, patch, link und unlink Blöcken
+*   In before und 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:
+
+```shell
+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)
+```
+
+### Multi-threading
+
+_Paraphrasiert von [dieser Antwort auf StackOverflow][so-answer] von Konstantin_
+
+Sinatra erlegt kein Nebenläufigkeitsmodell auf, sondern überlässt dies dem
+selbst gewählten Rack-Proxy (Server), so wie Thin, Puma oder WEBrick.
+Sinatra selbst ist Thread-sicher, somit ist es kein Problem wenn der
+Rack-Proxy ein anderes Threading-Modell für Nebenläufigkeit benutzt.
+Das heißt, dass wenn der Server gestartet wird, dass man die korrekte
+Aufrufsmethode benutzen sollte für den jeweiligen Rack-Proxy.
+Das folgende Beispiel ist eine Veranschaulichung eines mehrprozessigen
+Thin Servers:
+
+``` ruby
+# app.rb
+
+require 'sinatra/base'
+
+class App < Sinatra::Base
+  get '/' do
+    "Hello, World"
+  end
+end
+
+App.run!
+
+```
+
+Um den Server zu starten, führt man das folgende Kommando aus:
+
+``` shell
+thin --threaded start
+```
+
+[so-answer]: http://stackoverflow.com/questions/6278817/is-sinatra-multi-threaded/6282999#6282999)
+
+## Systemanforderungen
+
+Die folgenden Versionen werden offiziell unterstützt:
+
+<dl>
+<dt>Ruby 1.8.7</dt>
+<dd>1.8.7 wird vollständig unterstützt, ein Wechsel zu JRuby oder Rubinius wird
+aber empfohlen. Ruby 1.8.7 wird noch bis Sinatra 2.0 unterstützt werden. Frühere
+Versionen von Ruby sind nicht kompatibel mit Sinatra.</dd>
+
+<dt>Ruby 1.9.2</dt>
+<dd>1.9.2 wird mindestens bis Sinatra 1.5 voll unterstützt. Version 1.9.2p0
+sollte nicht verwendet werden, da unter Sinatra immer wieder Segfaults
+auftreten.</dd>
+
+<dt>Ruby 1.9.3</dt>
+<dd>1.9.3 wird vollständig unterstützt und empfohlen. Achtung, bei einem
+Upgrade von einer früheren Version von Ruby zu Ruby 1.9.3 werden alle Sessions
+ungültig. Ruby 1.9.3 wird bis Sinatra 2.0 unterstützt werden.</dd>
+
+<dt>Ruby 2.x</dt>
+<dd>2.x wird vollständig unterstützt.</dd>
+
+<dt>Rubinius</dt>
+<dd>Rubinius (Version >= 2.x) wird offiziell unterstützt. Es wird empfohlen, den
+<a href="http://puma.io">Puma Server</a> zu installieren (<tt>gem install puma
+</tt>)</dd>
+
+<dt>JRuby</dt>
+<dd>Aktuelle JRuby Versionen werden offiziell unterstützt. Es wird empfohlen,
+keine C-Erweiterungen zu verwenden und als Server Trinidad zu verwenden
+(<tt>gem install trinidad</tt>).</dd>
+</dl>
+
+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 (<tt>gem install control_tower</tt> wird empfohlen), Maglev, IronRuby
+*   Ruby 1.9.0 und 1.9.1
+
+Nicht offiziell unterstützt bedeutet, dass wenn Sachen nicht funktionieren,
+wir davon ausgehen, dass es nicht an Sinatra sondern an der jeweiligen
+Implementierung liegt.
+
+Im Rahmen unserer CI (Kontinuierlichen Integration) wird bereits ruby-head
+(zukünftige Versionen von MRI) mit eingebunden. Es kann davon ausgegangen
+werden, dass Sinatra MRI auch weiterhin vollständig unterstützen wird.
+
+Sinatra sollte auf jedem Betriebssystem laufen, dass einen funktionierenden
+Ruby-Interpreter aufweist.
+
+Sinatra läuft aktuell nicht unter Cardinal, SmallRuby, BlueRuby oder Ruby <= 1.8.7.
+
+## 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:
+
+```shell
+gem install sinatra --pre
+```
+
+### Mit Bundler
+
+Wenn die Applikation mit der neuesten Version von Sinatra und
+[Bundler](http://bundler.io) genutzt werden soll, empfehlen wir den
+nachfolgenden Weg.
+
+Soweit Bundler noch nicht installiert ist:
+
+```shell
+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:
+
+```shell
+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`:
+
+```shell
+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:
+
+```shell
+cd myproject/sinatra
+git pull
+```
+
+### Gem erstellen
+
+Aus der eigenen lokalen Kopie kann nun auch ein globales Gem gebaut werden:
+
+```shell
+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:
+
+```shell
+sudo rake install
+```
+
+## Versions-Verfahren
+
+Sinatra folgt dem sogenannten [Semantic Versioning](http://semver.org/), d.h.
+SemVer und SemVerTag.
+
+## Mehr
+
+*   [Projekt-Website](http://www.sinatrarb.com/) - Ergänzende Dokumentation,
+    News und Links zu anderen Ressourcen.
+*   [Mitmachen](http://www.sinatrarb.com/contributing.html) - Einen Fehler
+    gefunden? Brauchst du Hilfe? Hast du einen Patch?
+*   [Issue-Tracker](https://github.com/sinatra/sinatra/issues)
+*   [Twitter](https://twitter.com/sinatra)
+*   [Mailing-Liste](http://groups.google.com/group/sinatrarb)
+*   [#sinatra](irc://chat.freenode.net/#sinatra) auf http://freenode.net Es
+    gibt dort auch immer wieder deutschsprachige Entwickler, die gerne weiterhelfen.
+*   [Sinatra Book](https://github.com/sinatra/sinatra-book/) Kochbuch Tutorial
+*   [Sinatra Recipes](http://recipes.sinatrarb.com/) Sinatra-Rezepte aus der
+    Community
+*   API Dokumentation für die [aktuelle
+    Version](http://www.rubydoc.info//gems/sinatra) oder für
+    [HEAD](http://www.rubydoc.info/github/sinatra/sinatra) auf http://rubydoc.info
+*   [CI Server](https://travis-ci.org/sinatra/sinatra)