sinatra 1.0 → 1.1.a

data/CHANGES

@@ -1,4 +1,111 @@
-= 1.0 / 2010-01-28 (prerelease)
+= 1.1 / Not Yet Released
+
+ * Before and after filters now support pattern matching, including the
+   ability to use captures: "before('/user/:name') { |name| ... }". This
+   avoids manual path checking. No performance loss if patterns are avoided.
+   (Konstantin Haase)
+
+ * It is now possible to render SCSS files with the `scss` method, which
+   behaves exactly like `sass` except for the different file extension and
+   assuming the SCSS syntax. (Pedro Menezes, Konstantin Haase)
+
+ * Added `liquid`, `markdown`, `nokogiri`, `textile`, `rdoc`, `radius`,
+   `markaby`, and `coffee` rendering methods for rendering Liquid, Markdown,
+   Nokogiri, Textile, RDoc, Radius, Markaby and CoffeeScript templates.
+   (Konstantin Haase)
+
+ * Now supports byte-range requests (the HTTP_RANGE header) for static files.
+   Multi-range requests are not supported, however. (Jens Alfke)
+
+ * You can now use #settings method from class and top level for convenience.
+   (Konstantin Haase)
+
+ * Setting multiple values now no longer relies on #to_hash and therefore
+   accepts any Enumerable as parameter. (Simon Rozet)
+
+ * Nested templates default the `layout` option to `false` rather than `true`.
+   This eases the use of partials. If you wanted to render one haml template
+   embedded in another, you had to call `haml :partial, {}, :layout => false`.
+   As you almost never want the partial to be wrapped in the standard layout
+   in this situation, you now only have to call `haml :partial`. Passing in
+   `layout` explicitly is still possible. (Konstantin Haase)
+
+ * If a the return value of one of the render functions is used as a response
+   body and the content type has not been set explicitly, Sinatra chooses a
+   content type corresponding to the rendering engine rather than just using
+   "text/html". (Konstantin Haase)
+
+ * README is now available in French (Mickael Riga), German (Bernhard Essl,
+   Konstantin Haase, burningTyger), Hungarian (Janos Hardi) and Spanish
+   (Gabriel Andretta). The extremely outdated Japanese README has been updated
+   (Kouhei Yanagita).
+
+ * It is now possible to access Sinatra's template_cache from the outside.
+   (Nick Sutterer)
+
+ * The `last_modified` method now also accepts DateTime instances and makes
+   sure the header will always be set to a string. (Konstantin Haase)
+
+ * 599 now is a legal status code. (Steve Shreeve)
+
+ * This release is compatible with Ruby 1.9.2. Sinatra was trying to read
+   none existent files Ruby added to the call stack. (Shota Fukumori,
+   Konstantin Haase)
+
+ * Prevents a memory leak on 1.8.6 is production mode. Note, however, that
+   this is due to a bug in 1.8.6 and request will have the additional overhead
+   of parsing templates again on that version. It is recommended to use at
+   least Ruby 1.8.7. (Konstantin Haase)
+
+ * Compares last modified date correctly. `last_modified` was halting only
+   when the 'If-Modified-Since' header date was equal to the time specified.
+   Now, it halts when is equal or later than the time specified (Gabriel
+   Andretta).
+
+ * Sinatra is now usable in combination with Rails 3. When mounting a Sinatra
+   application under a subpath in Rails 3, the PATH_INFO is not prefixed with
+   a slash and no routes did match. (José Valim)
+
+ * Better handling of encodings in 1.9, defaults params encoding to UTF-8 and
+   respects Encoding.default_internal and Encoding.default_external.
+   (Konstantin Haase)
+
+ * `show_exeptions` handling is now triggered after custom error handlers, if
+   it is set to `:after_handlers`, thus not disabling those handler in
+   development mode. (pangel, Konstantin Haase)
+
+ * Added ability to handle weighted HTTP_ACCEPT headers. (Davide D'Agostino)
+
+ * `send_file` now always respects the `:type` option if set. Previously it
+   was discarded if no matching mime type was found, which made it impossible
+   to directly pass a mime type. (Konstantin Haase)
+
+ * `redirect` always redirects to an absolute URI, even if a relative URI was
+   passed. Ensures compatibility with RFC 2616 section 14.30. (Jean-Philippe
+   Garcia Ballester, Anthony Williams)
+
+ * Broken examples for using Erubis, Haml and Test::Unit in README have been
+   fixed. (Nick Sutterer, Doug Ireton, Jason Stewart, Eric Marden)
+
+ * Sinatra now handles SIGTERM correctly. (Patrick Collison)
+
+ * Fixes an issue with inline templates in modular applications that manually
+   call `run!`. (Konstantin Haase)
+
+ * Spaces after inline template names are now ignored (Konstantin Haase)
+
+ * It's now possible to use Sinatra with different package management
+   systems defining a custom require. (Konstantin Haase)
+
+ * Lighthouse has been dropped in favor of GitHub issues.
+
+ * Tilt is now a dependency and therefore no longer ships bundled with
+   Sinatra. (Ryan Tomayko, Konstantin Haase)
+
+ * Sinatra now depends on Rack 1.1 or higher. Rack 1.0 is no longer supported.
+   (Konstantin Haase)
+
+= 1.0 / 2010-03-23
 
  * It's now possible to register blocks to run after each request using
    after filters. After filters run at the end of each request, after

data/LICENSE

@@ -1,4 +1,4 @@
-Copyright (c) 2007, 2008, 2009 Blake Mizerany
+Copyright (c) 2007, 2008, 2009, 2010 Blake Mizerany
 
 Permission is hereby granted, free of charge, to any person
 obtaining a copy of this software and associated documentation

data/README.de.rdoc

@@ -0,0 +1,1024 @@
+= Sinatra
+<i>Wichtig: Dieses Dokument ist eine Übersetzung aus dem Englischen und unter Umständen nicht auf dem aktuellsten Stand.</i>
+
+Sinatra ist eine DSL, die das schnelle Erstellen von Webanwendungen in Ruby
+mit minimalen Aufwand ermöglicht:
+
+  # myapp.rb
+  require 'sinatra'
+  get '/' do
+    'Hallo Welt!'
+  end
+
+Einfach via rubygems installieren und starten:
+
+  gem install sinatra
+  ruby -rubygems myapp.rb
+
+Die Seite kann nun unter http://localhost:4567 betrachtet werden.
+
+== Routen
+
+In Sinatra wird eine Route durch eine HTTP-Methode und ein URL-Muster definiert. Jeder dieser Routen wird ein
+Ruby-Block zugeordnet.
+
+  get '/' do
+    .. zeige etwas ..
+  end
+
+  post '/' do
+    .. erstelle etwas ..
+  end
+
+  put '/' do
+    .. update etwas ..
+  end
+
+  delete '/' do
+    .. entferne etwas ..
+  end
+
+Die Routen werden in der Reihenfolge durchlaufen, in der sie definiert wurden.
+Das erste Routemuster, das mit dem Request übereinstimmt, wird ausgeführt.
+
+Die Muster der Routen können benannte Parameter beinhalten, die über den
+<tt>params</tt>-Hash zugänglich gemacht werden:
+
+  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 Blockparametern zugreifen:
+
+  get '/hallo/:name' do |n|
+    "Hallo #{n}!"
+  end
+
+Routenmuster können auch mit Splat- oder Wildcardparametern über das
+<tt>params[:splat]</tt> Array angesprochen werden.
+
+  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
+
+Routen mit regulären Ausdrücken sind auch möglich:
+
+  get %r{/hallo/([\w]+)} do
+    "Hallo, #{params[:captures].first}!"
+  end
+
+Und auch hier kann man Blockparameter nutzen:
+
+  get %r{/hallo/([\w]+)} do |c|
+    "Hallo, #{c}!"
+  end
+
+=== 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:
+
+  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+:
+
+  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
+
+Man kann auch relativ einfach eigene Bedingungen hinzufügen:
+
+  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
+
+=== Rückgabewerte
+
+Durch den Rückgabewert eines Routenblocks 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.
+
+Man kann jedes Objekt zurückgeben, bei dem es sich entweder um einenen validen
+Rack-Rückgabewert, einen validen Rack-Body oder einen HTTP Status Code
+handelt:
+
+* Ein Array mit drei Elementen: <tt>[Status (Fixnum), Headers (Hash), Response Body (hört auf #each)]</tt>
+* Ein Array mit zwei Elementen: <tt>[Status (Fixnum), Response Body (hört auf #each)]</tt>
+* Ein Objekt, das auf <tt>#each</tt> hört 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:
+
+    class Stream
+      def each
+        100.times { |i| yield "#{i}\n" }
+      end
+    end
+
+    get('/') { Stream.new }
+
+== Statische Dateien
+
+Statische Dateien werden aus dem <tt>./public</tt> Ordner ausgeliefert. Es ist
+möglich einen anderen Ort zu definieren, indem man die <tt>:public</tt> Option
+setzt:
+
+  set :public, File.dirname(__FILE__) + '/static'
+
+Zu beachten ist, dass der Ordnername public nicht Teil der URL ist. Die Datei
+<tt>./public/css/style.css</tt> ist unter
+<tt>http://example.com/css/style.css</tt> zu finden.
+
+== Views / Templates
+
+Standardmäßig wird davon ausgegangen, dass sich Templates im
+<tt>./views</tt> Ordner befinden. Man kann jedoch einen anderen Ordner
+festlegen:
+
+  set :views, File.dirname(__FILE__) + '/templates'
+
+Eine wichtige Sache, die man sich hierbei merken sollte, ist das man immer mit
+Symbols auf Templates verweisen sollte, auch wenn sich ein Template in einem
+Unterordner befindet (in diesen Fall <tt>:'subdir/template'</tt>).
+Renderingmethoden rendern jeden String direkt.
+
+=== Haml-Templates
+
+Das haml gem wird benötigt, um Haml-Templates rendern zu können:
+
+  ## haml muss eingebunden werden
+  require 'haml'
+
+  get '/' do
+    haml :index
+  end
+
+Dieser Code rendert <tt>./views/index.haml</tt>.
+
+{Hamls Optionen}[http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#options]
+können global durch die Sinatrakonfiguration gesetzt werden,
+siehe {Optionen und Konfiguration}[http://www.sinatrarb.com/configuration.html],
+und individuell überschrieben werden.
+
+  set :haml, :format => :html5 # Standard Haml-Format ist :xhtml
+
+  get '/' do
+    haml :index, :format => :html4 # überschrieben
+  end
+
+=== Erb-Templates
+
+  ## erb muss eingebunden werden
+  require 'erb'
+
+  get '/' do
+    erb :index
+  end
+
+Dieser Code rendert <tt>./views/index.erb</tt>.
+
+=== Erubis
+
+Das erubis gem wird benötigt, um Erubis-Templates rendern zu können:
+
+  ## erbubis muss eingebunden werden
+  require 'erubis'
+
+  get '/' do
+    erubis :index
+  end
+
+Dieser Code rendert <tt>./views/index.erubis</tt>.
+
+=== Builder-Templates
+
+Das buidler gem wird benötigt, um Builder-Templates rendern zu können:
+
+  ## builder muss eingebunden werden
+  require 'builder'
+
+  get '/' do
+    builder :index
+  end
+
+Dieser Code rendert <tt>./views/index.builder</tt>.
+
+=== Nokogiri-Templates
+
+Das nokogiri gem wird benötigt, um Nokogiri-Templates rendern zu können:
+
+  ## nokogiri muss eingebunden werden
+  require 'nokogiri'
+
+  get '/' do
+    nokogiri :index
+  end
+
+Dieser Code rendert <tt>./views/index.nokogiri</tt>.
+
+=== Sass-Templates
+
+Das haml gem wird benötigt, um SASS-Templates rendern zu können:
+
+  ## sass muss eingebunden werden
+  require 'sass'
+
+  get '/stylesheet.css' do
+    sass :stylesheet
+  end
+
+Dieser Code rendert <tt>./views/stylesheet.sass</tt>.
+
+{Sass Optionen}[http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#options]
+können global durch die Sinatra-Konfiguration gesetzt werden,
+siehe {Optionen und Konfiguration}[http://www.sinatrarb.com/configuration.html],
+und individuell überschrieben werden.
+
+  set :sass, :style => :compact # Standard Sass-Style ist :nested
+
+  get '/stylesheet.css' do
+    sass :stylesheet, :style => :expanded # überschrieben
+  end
+
+=== Scss-Templates
+
+Das haml gem wird benötigt, um SCSS-Templates rendern zu können:
+
+  ## sass muss eingebunden werden
+  require 'sass'
+
+  get '/stylesheet.css' do
+    scss :stylesheet
+  end
+
+Dieser Code rendert <tt>./views/stylesheet.scss</tt>.
+
+{Scss Optionen}[http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#options]
+können global durch die Sinatra-Konfiguration gesetzt werden,
+siehe {Optionen und Konfiguration}[http://www.sinatrarb.com/configuration.html],
+und individuell überschrieben werden.
+
+  set :scss, :style => :compact # Standard Scss-Style ist :nested
+
+  get '/stylesheet.css' do
+    scss :stylesheet, :style => :expanded # überschrieben
+  end
+
+=== Less-Templates
+
+Das less gem wird benötigt, um Less-Templates rendern zu können:
+
+  ## less muss eingebunden werden
+  require 'less'
+
+  get '/stylesheet.css' do
+    less :stylesheet
+  end
+
+Dieser Code rendert <tt>./views/stylesheet.less</tt>.
+
+=== Liquid-Templates
+
+Das liquid gem wird benötigt, um Liquid-Templates rendern zu können:
+
+  ## liquid muss eingebunden werden
+  require 'liquid'
+
+  get '/' do
+    liquid :index
+  end
+
+Dieser Code rendert <tt>./views/index.liquid</tt>.
+
+Da man aus Liquid-Templates heraus keine Methoden (abgesehen von +yield+)
+aufrufen kann, will man nahezu in allen Fällen +locals+ übergeben:
+
+  liquid :index, :locals => { :key => 'value' }
+
+=== Markdown-Templates
+
+Das rdiscount gem wird benötigt, um Markdown-Templates rendern zu können:
+
+  ## rdiscount muss eingebunden werden
+  require "rdiscount"
+
+  get '/' do
+    markdown :index
+  end
+
+Dieser Code rendert <tt>./views/index.markdown</tt> (+md+ und +mkd+ sind
+ebenfalls zulässige Dateiendungen).
+
+Da es weder möglich ist Methoden aufzurufen, noch +locals+ zu übergeben, ist
+es am sinnvollsten Markdown in Kombination mit einer anderen Template-Engine
+zu nutzen:
+
+  erb :overview, :locals => { :text => markdown(:introduction) }
+
+Es ist auch möglich die +markdown+ Methode aus anderen Templates heraus
+aufzurufen:
+
+  %h1 Hallo von Haml!
+  %p= markdown(:greetings)
+
+=== Textile-Templates
+
+Das RedCloth gem wird benötigt, um Textile-Templates rendern zu können:
+
+  ## redcloth muss eingebunden werden
+  require "redcloth"
+
+  get '/' do
+    textile :index
+  end
+
+Dieser Code rendert <tt>./views/index.textile</tt>.
+
+Da es weder möglich ist Methoden aufzurufen, noch +locals+ zu übergeben, ist
+es am sinnvollsten Textile in Kombination mit einer anderen Template-Engine
+zu nutzen:
+
+  erb :overview, :locals => { :text => textile(:introduction) }
+
+Es ist auch möglich die +textile+ Methode aus anderen Templates heraus
+aufzurufen:
+
+  %h1 Hallo von Haml!
+  %p= textile(:greetings)
+
+=== RDoc-Templates
+
+Das rdoc gem wird benötigt, um RDoc-Templates rendern zu können:
+
+  ## RDoc muss eingebunden werden
+  require "rdoc"
+
+  get '/' do
+    rdoc :index
+  end
+
+Dieser Code rendert <tt>./views/index.rdoc</tt>.
+
+Da es weder möglich ist Methoden aufzurufen, noch +locals+ zu übergeben, ist
+es am sinnvollsten RDoc in Kombination mit einer anderen Template-Engine
+zu nutzen:
+
+  erb :overview, :locals => { :text => rdoc(:introduction) }
+
+Es ist auch möglich die +rdoc+ Methode aus anderen Templates heraus
+aufzurufen:
+
+  %h1 Hallo von Haml!
+  %p= rdoc(:greetings)
+
+=== Radius-Templates
+
+Das radius gem wird benötigt, um Radius-Templates rendern zu können:
+
+  ## radius muss eingebunden werden
+  require 'radius'
+
+  get '/' do
+    radius :index
+  end
+
+Dieser Code rendert <tt>./views/index.radius</tt>.
+
+Da man aus Radius-Templates heraus keine Methoden (abgesehen von +yield+)
+aufrufen kann, will man nahezu in allen Fällen +locals+ übergeben:
+
+  radius :index, :locals => { :key => 'value' }
+
+=== Markaby-Templates
+
+Das markaby gem wird benötigt, um Markaby-Templates rendern zu können:
+
+  ## markaby muss eingebunden werden
+  require 'markaby'
+
+  get '/' do
+    markaby :index
+  end
+
+Dieser Code rendert <tt>./views/index.mab</tt>.
+
+=== CoffeScript-Templates
+
+Das coffee-script gem und das `coffee`-Programm werden benötigt, um CoffeScript-Templates rendern zu können:
+
+  ## coffee-script muss eingebunden werden
+  require 'coffee-script'
+
+  get '/application.js' do
+    coffee :application
+  end
+
+Dieser Code rendert <tt>./views/application.coffee</tt>.
+
+=== Inline-Templates
+
+  get '/' do
+    haml '%div.title Hallo Welt'
+  end
+
+Rendert den Inline-Template-String.
+
+=== Auf Variablen in Templates zugreifen
+
+Templates werden im selben Kontext ausgeführt wie Routen. Instanzvariablen in
+Routen sind auch direkt im Template verfügbar:
+
+  get '/:id' do
+    @foo = Foo.find(params[:id])
+    haml '%h1= @foo.name'
+  end
+
+Oder durch einen expliziten Hash von lokalen Variablen:
+
+  get '/:id' do
+    foo = Foo.find(params[:id])
+    haml '%h1= foo.name', :locals => { :foo => 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:
+
+  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 <tt>require
+'sinatra'</tt> aufruft, werden automatisch geladen. Um andere Inline-Templates
+in anderen Dateien aufzurufen, muss <tt>enable :inline_templates</tt> explizit
+verwendet werden.
+
+=== Benannte Templates
+
+Templates können auch mit der Top-Level <tt>template</tt>-Methode definiert
+werden:
+
+  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 <tt>:layout => false</tt> kann das Ausführen verhindert werden.
+
+  get '/' do
+    haml :index, :layout => !request.xhr?
+  end
+
+== Helfer
+
+Durch die Top-Level <tt>helpers</tt>-Methode, werden sogenannte Helfer-Methoden
+definiert, die in Routen und Templates verwendet werden können:
+
+  helpers do
+    def bar(name)
+      "#{name}bar"
+    end
+  end
+
+  get '/:name' do
+    bar(params[:name])
+  end
+
+== Filter
+
+Before-Filter werden immer vor jedem Request in dem selben Kontext wie danach
+die Routen ausgeführt. So kann man etwa Request und Antwort ändern. Gesetzte
+Instanzvariablen in Filtern können in Routen und Templates verwendet werden:
+
+  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 im selben Kontext ausgeführt, und
+können ebenfalls Request und Antwort ändern. In Before-Filtern gesetzte
+Instanzvariablen können in After-Filterm verwendet werden:
+
+  after do
+    puts response.status
+  end
+
+Filter können optional auch mit einem Pattern ausgestattet werden, welche auf den Request-Pfad passen müssen, damit der Filter ausgeführt wird:
+
+  before '/protected/*' do
+    authenticate!
+  end
+
+  after '/create/:slug' do |slug|
+    session[:last_slug] = slug
+  end
+
+== Anhalten
+
+Zum sofortigen stoppen eines Request in einem Filter oder einer Route:
+
+  halt
+
+Der Status kann beim stoppen auch angegeben werden:
+
+  halt 410
+
+Oder auch den Response-Body:
+
+  halt 'Hier steht der Body'
+
+Oder beides:
+
+  halt 401, 'verschwinde!'
+
+Sogar mit Headers:
+
+  halt 402, {'Content-Type' => 'text/plain'}, 'Rache'
+
+== Weiterspringen
+
+Eine Route kann mittels <tt>pass</tt> zu der nächsten passenden Route springen:
+
+  get '/raten/:wer' do
+    pass unless params[:wer] == 'Frank'
+    'Du hast mich!'
+  end
+
+  get '/raten/*' do
+    'Du hast mich verfehlt!'
+  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.
+
+== Das Request-Objekt
+
+Auf das `request`-Objeket der eigehenden Anfrage kann man vom Anfragescope aus zugreifen:
+
+  # App läuft unter http://example.com/example
+  get '/foo' do
+    request.body              # Request Body des Clients (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 von request.body
+    request.media_type        # Media-Type von request.body
+    request.host              # "example.com"
+    request.get?              # true (ähnliche Methoden für andere Verben)
+    request.form_data?        # false
+    request["SOME_HEADER"]    # Wert des SOME_HEADER-headers
+    request.referer           # der Referrer des Clients oder '/'
+    request.user_agent        # User Agent (genutzt von :agent-Bedingung)
+    request.cookies           # Hash der Cookies
+    request.xhr?              # Ist dies eine Ajax-Anfrage?
+    request.url               # "http://example.com/example/foo"
+    request.path              # "/example/foo"
+    request.ip                # Client IP-Addresse
+    request.secure?           # false
+    requuest.env              # env-Hash den Rack durchreicht
+  end
+
+Manche Optionen, wie etwa <tt>script_name</tt> oder <tt>path_info</tt> sind
+auch schreibbar:
+
+  before { request.path_info = "/" }
+  
+  get "/" do
+    "Alle Anfragen kommen hier an!"
+  end
+
+Der <tt>request.body</tt> ist einn IO- oder StringIO-Objekt:
+
+  post "/api" do
+    request.body.rewind  # falls schon jemand davon gelesen hat
+    daten = JSON.parse request.body.read
+    "Hallo #{daten['name']}!"
+  end
+
+== Konfiguration
+
+Wird einmal beim Starten in jedweder Umgebung ausgeführt:
+
+  configure do
+    ...
+  end
+
+Läuft nur, wenn die Umgebung (RACK_ENV Umgebungsvariable) auf
+<tt>:production</tt> gesetzt ist:
+
+  configure :production do
+    ...
+  end
+
+Läuft nur, wenn die Umgebung auf <tt>:production</tt> oder auf <tt>:test</tt>
+gesetzt ist:
+
+  configure :production, :test do
+    ...
+  end
+
+== Fehlerbehandlung
+
+Error Handler laufen im selben Kontext wie Routen und Filter, was bedeutet,
+dass alle Goodies wie <tt>haml</tt>, <tt>erb</tt>, <tt>halt</tt>, etc.
+verwendet werden können.
+
+=== Nicht gefunden
+
+Wenn eine <tt>Sinatra::NotFound</tt> Exception geworfen wird oder der Statuscode 404 ist, wird der <tt>not_found</tt> Handler ausgeführt:
+
+  not_found do
+    'Seite kann nirgendwo gefunden werden.'
+  end
+
+=== Fehler
+
+Der +error+ Handler wird immer ausgeführt, wenn eine Exception in einem Routenblock
+oder in einen Filter geworfen wurde. Die Exception kann über die
+<tt>sinatra.error</tt> Rack-Variable angesprochen werden:
+
+  error do
+    'Entschuldige es gab einen hässlichen Fehler - ' + env['sinatra.error'].name
+  end
+
+Benutzerdefinierte Fehler:
+
+  error MeinFehler do
+    'Was passiert ist...' + request.env['sinatra.error'].message
+  end
+
+Dann, wenn das passiert:
+
+  get '/' do
+    raise MeinFehler, 'etwas schlechtes'
+  end
+
+Bekommt man dieses:
+
+  Was passiert ist... etwas schlechtes
+
+Alternativ kann ein Error Handler auch für Statuscode definiert werden:
+
+  error 403 do
+    'Zugriff verboten'
+  end
+
+  get '/geheim' do
+    403
+  end
+
+Oder ein Statuscode-Bereich:
+
+  error 400..510 do
+    'Boom'
+  end
+
+Sinatra setzt verschiedene <tt>not_found</tt> und <tt>error</tt>
+Handler in der Development Umgebung.
+
+== Mime-Types
+
+Wenn <tt>send_file</tt> oder statische Dateien verwendet werden, kann es
+vorkommen, dass Sinatra den Mime-Typ nicht kennt. Registriert wird dieser mit
++mime_type+ per Dateiendung:
+
+  mime_type :foo, 'text/foo'
+
+Es kann aber auch der +content_type+ Helfer verwendet werden:
+
+  content_type :foo
+
+== Rack Middleware
+
+Sinatra baut auf Rack[http://rack.rubyforge.org/], einem minimalen Standardinterface für Ruby Webframeworks. Eines der interessantesten
+Features für Entwickler ist der Support von Middleware, die
+zwischen den Server und die Anwendung geschaltet wird und so HTTP
+Request und/oder Antwort überwachen und/oder manipulieren kann.
+
+Sinatra macht das erstellen von Middleware-Verkettungen mit der Top-Level
+Methode +use+ zu einem Kinderspiel:
+
+  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 entgegen nimmt:
+
+  use Rack::Auth::Basic do |username, password|
+    username == 'admin' && password == 'geheim'
+  end
+
+Rack bietet eine Vielzahl von standard Middleware für Logging, Debugging,
+URL-Routing, Authentifizierung und Session-Verarbeitung.
+Sinatra verwendet viele von diesen Komponenten automatisch, abhängig von der
+Konfiguration. So muss man häufig +use+ nicht explizit verwenden.
+
+== Testen
+
+Sinatra Tests können mit jedem auf Rack aufbauendem Test Framework geschrieben
+werden. {Rack::Test}[http://gitrdoc.com/brynary/rack-test] wird empfohlen:
+
+  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
+
+Anmerkung: Das eingebaute Sinatra::Test Modul und die Sinatra::TestHarness
+Klasse werden seit Version 0.9.2 nicht mehr unterstützt.
+
+== Sinatra::Base - Middleware, Bibliotheken, und modulare Anwendungen
+
+Das Definitieren einer Top-Level Anwendung funktioniert gut für
+Microanwendungen, hat aber Nachteile, wenn man wiederverwendbare Komponenten
+wie Middleware, Rails Metal, einfache Bibliotheken mit Server Komponenten
+oder auch Sinatra Erweiterungen bauen will.
+Die Top-Level DSL belastet den Objekt-Namespace und setzt einen Microanwendungsstil voraus (eine einzelne Anwendungsdatei, ./public und ./views
+Ordner, Logging, Exception-Detail-Seite, usw.). Genau hier kommt Sinatra::Base
+ins Spiel:
+
+  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 Serverkomponente
+einer Bibliothek:
+
+   MyApp.run! :host => 'localhost', :port => 9090
+
+Die Methoden der Sinatra::Base-Subklasse sind genau die selben wie die
+der Top-Level DSL. Die meisten Top-Level Anwendungen können mit nur zwei Veränderungen zu Sinatra::Base-Komponenten konvertiert werden:
+
+* Die Datei sollte <tt>require 'sinatra/base'</tt> anstelle von
+  <tt>require 'sinatra/base'</tt> 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.
+
+<tt>Sinatra::Base</tt> ist ein unbeschriebense Blatt. Die meisten Optionen sind per default deaktiviert. Das betrifft auch den eingebauten Server. Siehe {Optionen und Konfiguration}[http://sinatra.github.com/configuration.html] für Details über möglichen Optionen.
+
+=== Sinatra als Middleware nutzen
+
+Es ist nicht nur möglich andere Rack-Middleware mit Sinatra zu nutzen, man
+kann außerdem jede Sinatra-Anwendung selbst als Middlware vor jeden beliebigen
+Rack-Endpunkt hängen. Bei diesem Endpunkt muss es sich nicht um eine andere
+Sinatra-Anwendung handen, es kann jede andere Rack-Anwendung sein
+(Rails/Ramaze/Camping/...).
+
+  require 'sinatra/base'
+
+  class LoginScreen < Sinatra::Base
+    enable :session
+  
+    get('/login') { haml :login }
+  
+    post('/login') do
+      if params[:name] = 'admin' and 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
+
+== Scopes und Bindung
+
+In welchem Scope man sich gerade befinded legt fest, welche Methoden und
+Variablen zur Verfügung stehen.
+
+=== Anwendungs- oder Klassenscope
+
+Jede Sinatra-Anwendung entspricht einer Sinatra::Base-Subklasse. Falls man die Top-Level-DSL verwendet (<tt>require 'sinatra'</tt>), so handelt es sich hierbei um Sinatra::Application, andernfalls is es jene Subklasse, die man explizit angelegt hat. Auf Klassenebene stehen Methoden wie `get` oder `before` zur Verfügung, man hat 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:
+
+  class MyApp << Sinatra::Base
+    # Hey, ich bin im Anwendungsscope!
+    set :foo, 42
+    foo # => 42
+    
+    get '/foo' do
+      # Hey, ich bin nicht mehr im Anwendungsscope!
+    end
+  end
+
+Im Anwendungsscope befindet man sich:
+
+* In der Anwenungsklasse.
+* In Methoden die von Erweiterungen definiert werden.
+* Im Block, der an `helpers` übergeben wird.
+* In Procs und Blöcken die an `set` übergeben werden.
+
+Man kann auf das Scope-Object (die Klasse) wie folgt zugreifen:
+
+* Über das Objekt, dass an den `configure`-Block übergeben wird (<tt>configure
+  { |c| ... }</tt>).
+* `settings` aus den anderen Scopes heraus.
+
+=== Anfrage- oder Instanzscope
+
+Für jede eingehende Anfrage wird eine neue Instanz der Anwendungsklasse erstellt und alle Handlers werden in diesem Scope ausgeführt. Aus diesem Scope heraus kann man auf `request` oder `session` zugreifen und Methoden wie `erb` oder `haml` aufrufen. Man kann mit der `settings` Methode außerdem auf den Anwengungsscope zugreifen.
+
+  class MyApp << Sinatra::Base
+    # Hey, ich bin im Anwendungsscope!
+    get '/neue_route/:name' do
+      # Anfragescope für '/neue_route/:name'
+      @value = 42
+      
+      settings.get "/#{params[:name]}" do
+        # Anfragescope für "/#{params[:name]}"
+        @value # => nil (nicht die gleiche Anfrage)
+      end
+      
+      "Route definiert!"
+    end
+  end
+
+Im Anfragescope befindet man sich:
+
+* In get/head/post/put/delete Blöcken
+* In before/after Filtern
+* In Helfermethoden
+* In Templates
+
+=== Delegation-Scope
+
+Vom Delegation-Scope aus werden Methoden einfach an den Klassenscope
+weitergeleitet. Dieser verhält sich jedoch nicht 100%ig wie der Klassenscope,
+da man nicht die Bindung der Klasse besitzt: Nur Methoden, die explizit als
+deligierbar markiert wurden stehen hier zur Verfügung und man kann nicht auf
+die Variablen des Klassenscopes zugreifen (mit anderen Worten: man hat ein
+anderes `self`). Man kann mit <tt>Sinatra::Delegator.delegate
+:methoden_name</tt> auch weitere Delegationen hinzufügen.
+
+Im Delegation-Scop befindet man sich:
+
+* Im Top-Level, wenn man <tt>require 'sinatra'</tt> aufgerufen hat.
+* In einem Objekt, dass 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#L25].
+
+== 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)
+
+== Der neueste Stand (The Bleeding Edge)
+
+Um auf den neuesten Stand von Sinatras Code zu sein, kann eine lokale Kopie
+angelegt werden. Gestartet wird in der Anwendung mit dem <tt>sinatra/lib</tt>
+Ordner im <tt>LOAD_PATH</tt>:
+
+  cd myapp
+  git clone git://github.com/sinatra/sinatra.git
+  ruby -Isinatra/lib myapp.rb
+
+Alternativ kann der <tt>sinatra/lib</tt> Ordner zum <tt>LOAD_PATH</tt> in
+der Anwendung hinzugefügt werden:
+
+  $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
+
+== Mehr
+
+* {Projekt Website}[http://sinatra.github.com/] - Ergänzende Dokumentation,
+  News und Links zu anderen Ressourcen.
+* {Hilfe beisteuern}[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]
+* {Mailingliste}[http://groups.google.com/group/sinatrarb]
+* {IRC: #sinatra}[irc://chat.freenode.net/#sinatra] auf http://freenode.net