2010-01-01 10:13:42 -05:00
= Sinatra
2010-09-22 01:50:09 -04:00
<i>Wichtig: Dieses Dokument ist eine Übersetzung aus dem Englischen und unter Umständen nicht auf dem aktuellsten Stand.</i>
2010-01-01 10:13:42 -05:00
2010-09-29 14:14:06 -04:00
Sinatra ist eine DSL, die das schnelle Erstellen von Webanwendungen in Ruby
2010-09-22 01:43:28 -04:00
mit minimalen Aufwand ermöglicht:
2010-01-01 10:13:42 -05:00
# myapp.rb
require 'sinatra'
get '/' do
'Hallo Welt!'
end
2010-09-29 14:14:06 -04:00
Einfach via rubygems installieren und starten:
2010-01-01 10:13:42 -05:00
2010-09-07 04:23:28 -04:00
gem install sinatra
ruby -rubygems myapp.rb
2010-01-01 10:13:42 -05:00
2010-09-10 10:34:41 -04:00
Die Seite kann nun unter http://localhost:4567 betrachtet werden.
2010-01-01 10:13:42 -05:00
== Routen
2010-09-29 14:14:06 -04:00
In Sinatra wird eine Route durch eine HTTP-Methode und ein URL-Muster definiert. Jeder dieser Routen wird ein
Ruby-Block zugeordnet.
2010-01-01 10:13:42 -05:00
get '/' do
2010-09-29 14:14:06 -04:00
.. zeige etwas ..
2010-01-01 10:13:42 -05:00
end
post '/' do
.. erstelle etwas ..
end
put '/' do
.. update etwas ..
end
delete '/' do
.. entferne etwas ..
end
2010-09-25 17:57:23 -04:00
Die Routen werden in der Reihenfolge durchlaufen, in der sie definiert wurden.
2010-09-10 10:34:41 -04:00
Das erste Routemuster, das mit dem Request übereinstimmt, wird ausgeführt.
2010-01-01 10:13:42 -05:00
2010-09-10 10:34:41 -04:00
Die Muster der Routen können benannte Parameter beinhalten, die über den
2010-09-25 17:57:23 -04:00
<tt>params</tt>-Hash zugänglich gemacht werden:
2010-01-01 10:13:42 -05:00
get '/hallo/:name' do
# passt auf "GET /hallo/foo" und "GET /hallo/bar"
# params[:name] ist 'foo' oder 'bar'
"Hallo #{params[:name]}!"
end
2010-09-10 10:34:41 -04:00
Man kann auf diese auch mit Blockparametern zugreifen:
2010-01-01 10:13:42 -05:00
get '/hallo/:name' do |n|
"Hallo #{n}!"
end
2010-09-10 10:34:41 -04:00
Routenmuster können auch mit Splat- oder Wildcardparametern über das
2010-01-01 10:13:42 -05:00
<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
2010-09-10 10:34:41 -04:00
Routen mit regulären Ausdrücken sind auch möglich:
2010-01-01 10:13:42 -05:00
get %r{/hallo/([\w]+)} do
"Hallo, #{params[:captures].first}!"
end
2010-09-29 14:14:06 -04:00
Und auch hier kann man Blockparameter nutzen:
2010-01-01 10:13:42 -05:00
get %r{/hallo/([\w]+)} do |c|
"Hallo, #{c}!"
end
2010-09-10 10:34:41 -04:00
=== Bedingungen
An Routen können eine Vielzahl von Bedingungen angehängt werden, die erfüllt
2010-09-29 14:14:06 -04:00
sein müssen, damit der Block ausgeführt wird. Möglich wäre etwa eine
2010-09-10 10:34:41 -04:00
Einschränkung des User Agents:
2010-01-01 10:13:42 -05:00
get '/foo', :agent => /Songbird (\d\.\d)[\d\/]*?/ do
2010-09-10 10:34:41 -04:00
"Du verwendest Songbird Version #{params[:agent][0]}"
2010-01-01 10:13:42 -05:00
end
get '/foo' do
# passt auf andere Browser
end
2010-09-10 10:34:41 -04:00
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
2010-09-29 14:14:06 -04:00
weitergegeben wird. Im Normalfall handelt es sich hierbei, wie
in den vorangehenden Beispielen zu sehen war, um einen String. Es werden allerdings auch andere
2010-09-10 10:34:41 -04:00
Werte akzeptiert.
2010-09-29 14:14:06 -04:00
Man kann jedes Objekt zurückgeben, bei dem es sich entweder um einenen validen
2010-09-10 10:34:41 -04:00
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 }
2010-01-01 10:13:42 -05:00
== Statische Dateien
2010-09-10 10:34:41 -04:00
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:
2010-01-01 10:13:42 -05:00
set :public, File.dirname(__FILE__) + '/static'
2010-09-10 10:34:41 -04:00
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.
2010-01-01 10:13:42 -05:00
2010-09-10 10:34:41 -04:00
== Views / Templates
2010-01-01 10:13:42 -05:00
2010-09-29 14:14:06 -04:00
Standardmäßig wird davon ausgegangen, dass sich Templates im
2010-09-10 10:34:41 -04:00
<tt>./views</tt> Ordner befinden. Man kann jedoch einen anderen Ordner
festlegen:
2010-01-01 10:13:42 -05:00
set :views, File.dirname(__FILE__) + '/templates'
2010-09-10 10:34:41 -04:00
Eine wichtige Sache, die man sich hierbei merken sollte, ist das man immer mit
2010-09-29 14:14:06 -04:00
Symbols auf Templates verweisen sollte, auch wenn sich ein Template in einem
2010-09-10 10:34:41 -04:00
Unterordner befindet (in diesen Fall <tt>:'subdir/template'</tt>).
Renderingmethoden rendern jeden String direkt.
2010-01-01 10:13:42 -05:00
2010-09-11 07:56:10 -04:00
=== Haml-Templates
2010-01-01 10:13:42 -05:00
2010-09-29 14:14:06 -04:00
Das haml gem wird benötigt, um Haml-Templates rendern zu können:
2010-01-01 10:13:42 -05:00
## haml muss eingebunden werden
require 'haml'
get '/' do
haml :index
end
2010-09-10 10:34:41 -04:00
Dieser Code rendert <tt>./views/index.haml</tt>.
2010-01-01 10:13:42 -05:00
2010-05-26 14:24:31 -04:00
{Hamls Optionen}[http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#options]
2010-09-10 10:34:41 -04:00
können global durch die Sinatrakonfiguration gesetzt werden,
2010-01-01 10:13:42 -05:00
siehe {Optionen und Konfiguration}[http://www.sinatrarb.com/configuration.html],
und individuell überschrieben werden.
2010-09-10 10:34:41 -04:00
set :haml, :format => :html5 # Standard Haml-Format ist :xhtml
2010-01-01 10:13:42 -05:00
get '/' do
2010-09-10 10:34:41 -04:00
haml :index, :format => :html4 # überschrieben
2010-01-01 10:13:42 -05:00
end
2010-09-11 07:56:10 -04:00
=== Erb-Templates
2010-01-01 10:13:42 -05:00
## erb muss eingebunden werden
require 'erb'
get '/' do
erb :index
end
2010-09-10 10:34:41 -04:00
Dieser Code rendert <tt>./views/index.erb</tt>.
2010-01-01 10:13:42 -05:00
=== Erubis
2010-09-29 14:14:06 -04:00
Das erubis gem wird benötigt, um Erubis-Templates rendern zu können:
2010-01-01 10:13:42 -05:00
## erbubis muss eingebunden werden
require 'erubis'
get '/' do
erubis :index
end
2010-09-10 10:34:41 -04:00
Dieser Code rendert <tt>./views/index.erubis</tt>.
2010-01-01 10:13:42 -05:00
2010-09-11 07:56:10 -04:00
=== Builder-Templates
2010-01-01 10:13:42 -05:00
2010-09-29 14:14:06 -04:00
Das buidler gem wird benötigt, um Builder-Templates rendern zu können:
2010-01-01 10:13:42 -05:00
## builder muss eingebunden werden
require 'builder'
get '/' do
builder :index
end
2010-09-10 10:34:41 -04:00
Dieser Code rendert <tt>./views/index.builder</tt>.
2010-01-01 10:13:42 -05:00
2010-09-11 07:56:10 -04:00
=== Sass-Templates
2010-01-01 10:13:42 -05:00
2010-09-29 14:14:06 -04:00
Das haml gem wird benötigt, um SASS-Templates rendern zu können:
2010-01-01 10:13:42 -05:00
2010-09-10 10:34:41 -04:00
## sass muss eingebunden werden
2010-01-01 10:13:42 -05:00
require 'sass'
get '/stylesheet.css' do
sass :stylesheet
end
2010-09-10 10:34:41 -04:00
Dieser Code rendert <tt>./views/stylesheet.sass</tt>.
2010-01-01 10:13:42 -05:00
2010-05-26 14:24:31 -04:00
{Sass Optionen}[http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#options]
2010-09-10 10:34:41 -04:00
können global durch die Sinatra-Konfiguration gesetzt werden,
2010-01-01 10:13:42 -05:00
siehe {Optionen und Konfiguration}[http://www.sinatrarb.com/configuration.html],
und individuell überschrieben werden.
2010-09-10 10:34:41 -04:00
set :sass, :style => :compact # Standard Sass-Style ist :nested
2010-01-01 10:13:42 -05:00
get '/stylesheet.css' do
sass :stylesheet, :style => :expanded # überschrieben
end
2010-09-11 07:56:10 -04:00
=== Scss-Templates
2010-09-10 10:34:41 -04:00
2010-09-29 14:14:06 -04:00
Das haml gem wird benötigt, um SCSS-Templates rendern zu können:
2010-09-10 10:34:41 -04:00
## 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
2010-09-11 07:56:10 -04:00
=== Less-Templates
2010-09-10 10:34:41 -04:00
2010-09-29 14:14:06 -04:00
Das less gem wird benötigt, um Less-Templates rendern zu können:
2010-09-10 10:34:41 -04:00
## less muss eingebunden werden
require 'less'
get '/stylesheet.css' do
less :stylesheet
end
Dieser Code rendert <tt>./views/stylesheet.less</tt>.
2010-09-11 07:56:10 -04:00
=== Liquid-Templates
2010-09-11 07:53:49 -04:00
2010-09-29 14:14:06 -04:00
Das liquid gem wird benötigt, um Liquid-Templates rendern zu können:
2010-09-11 07:53:49 -04:00
## 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' }
2010-09-11 08:34:41 -04:00
=== Markdown-Templates
2010-09-29 14:14:06 -04:00
Das rdiscount gem wird benötigt, um Markdown-Templates rendern zu können:
2010-09-11 08:34:41 -04:00
## 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)
2010-09-11 08:52:55 -04:00
=== Textile-Templates
2010-09-29 14:14:06 -04:00
Das RedCloth gem wird benötigt, um Textile-Templates rendern zu können:
2010-09-11 08:52:55 -04:00
## 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)
2010-09-12 07:59:00 -04:00
=== RDoc-Templates
2010-09-29 14:14:06 -04:00
Das rdoc gem wird benötigt, um RDoc-Templates rendern zu können:
2010-09-12 07:59:00 -04:00
2010-09-29 14:14:06 -04:00
## RDoc muss eingebunden werden
2010-09-12 07:59:00 -04:00
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)
2010-09-12 09:14:45 -04:00
=== Radius-Templates
2010-09-29 14:14:06 -04:00
Das radius gem wird benötigt, um Radius-Templates rendern zu können:
2010-09-12 09:14:45 -04:00
## 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' }
2010-09-12 11:00:33 -04:00
=== Markaby-Templates
2010-09-29 14:14:06 -04:00
Das markaby gem wird benötigt, um Markaby-Templates rendern zu können:
2010-09-12 11:00:33 -04:00
## markaby muss eingebunden werden
require 'markaby'
get '/' do
markaby :index
end
Dieser Code rendert <tt>./views/index.mab</tt>.
2010-09-12 17:09:10 -04:00
=== CoffeScript-Templates
2010-09-29 14:14:06 -04:00
Das coffee-script gem und das `coffee`-Programm werden benötigt, um CoffeScript-Templates rendern zu können:
2010-09-12 17:09:10 -04:00
## coffee-script muss eingebunden werden
require 'coffee-script'
get '/application.js' do
coffee :application
end
Dieser Code rendert <tt>./views/application.coffee</tt>.
2010-09-11 07:56:10 -04:00
=== Inline-Templates
2010-01-01 10:13:42 -05:00
get '/' do
haml '%div.title Hallo Welt'
end
2010-09-11 07:56:10 -04:00
Rendert den Inline-Template-String.
2010-01-01 10:13:42 -05:00
=== Auf Variablen in Templates zugreifen
2010-09-10 10:34:41 -04:00
Templates werden im selben Kontext ausgeführt wie Routen. Instanzvariablen in
Routen sind auch direkt im Template verfügbar:
2010-01-01 10:13:42 -05:00
get '/:id' do
@foo = Foo.find(params[:id])
haml '%h1= @foo.name'
end
2010-09-10 10:34:41 -04:00
Oder durch einen expliziten Hash von lokalen Variablen:
2010-01-01 10:13:42 -05:00
get '/:id' do
foo = Foo.find(params[:id])
haml '%h1= foo.name', :locals => { :foo => foo }
end
2010-09-10 10:34:41 -04:00
Dies wird typischerweise bei Verwendung von Subtemplates (partials) in anderen
2010-01-01 10:13:42 -05:00
Templates eingesetzt.
2010-09-10 10:34:41 -04:00
=== Inline-Templates
2010-01-01 10:13:42 -05:00
2010-09-10 10:34:41 -04:00
Templates können auch am Ende der Datei definiert werden:
2010-01-01 10:13:42 -05:00
require 'sinatra'
get '/' do
haml :index
end
__END__
@@ layout
%html
= yield
@@ index
%div.title Hallo Welt!!!!!
2010-09-29 14:14:06 -04:00
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
2010-09-10 10:34:41 -04:00
verwendet werden.
2010-01-01 10:13:42 -05:00
=== Benannte Templates
2010-09-10 10:34:41 -04:00
Templates können auch mit der Top-Level <tt>template</tt>-Methode definiert
2010-01-01 10:13:42 -05:00
werden:
template :layout do
"%html\n =yield\n"
end
template :index do
'%div.title Hallo Welt!'
end
get '/' do
haml :index
end
2010-09-29 14:14:06 -04:00
Wenn ein Template mit dem Namen "layout" existiert, wird es bei jedem Aufruf
2010-01-01 10:13:42 -05:00
verwendet. Durch <tt>:layout => false</tt> kann das Ausführen verhindert werden.
get '/' do
haml :index, :layout => !request.xhr?
end
== Helfer
2010-09-29 14:14:06 -04:00
Durch die Top-Level <tt>helpers</tt>-Methode, werden sogenannte Helfer-Methoden
2010-09-10 10:34:41 -04:00
definiert, die in Routen und Templates verwendet werden können:
2010-01-01 10:13:42 -05:00
helpers do
def bar(name)
"#{name}bar"
end
end
get '/:name' do
bar(params[:name])
end
== Filter
2010-09-10 10:34:41 -04:00
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:
2010-01-01 10:13:42 -05:00
before do
@note = 'Hi!'
request.path_info = '/foo/bar/baz'
end
get '/foo/*' do
@note #=> 'Hi!'
params[:splat] #=> 'bar/baz'
end
2010-09-10 10:34:41 -04:00
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:
2010-01-01 10:13:42 -05:00
after do
puts response.status
end
2010-09-29 14:14:06 -04:00
Filter können optional auch mit einem Pattern ausgestattet werden, welche auf den Request-Pfad passen müssen, damit der Filter ausgeführt wird:
2010-09-10 10:34:41 -04:00
before '/protected/*' do
authenticate!
end
after '/create/:slug' do |slug|
session[:last_slug] = slug
end
2010-01-01 10:13:42 -05:00
== Anhalten
2010-09-29 14:14:06 -04:00
Zum sofortigen stoppen eines Request in einem Filter oder einer Route:
2010-01-01 10:13:42 -05:00
halt
2010-09-10 10:34:41 -04:00
Der Status kann beim stoppen auch angegeben werden:
2010-01-01 10:13:42 -05:00
halt 410
2010-09-10 10:34:41 -04:00
Oder auch den Response-Body:
2010-01-01 10:13:42 -05:00
2010-09-10 10:34:41 -04:00
halt 'Hier steht der Body'
2010-01-01 10:13:42 -05:00
2010-09-10 10:34:41 -04:00
Oder beides:
2010-01-01 10:13:42 -05:00
halt 401, 'verschwinde!'
2010-09-10 10:34:41 -04:00
Sogar mit Headers:
2010-01-01 10:13:42 -05:00
halt 402, {'Content-Type' => 'text/plain'}, 'Rache'
== Weiterspringen
2010-09-10 10:34:41 -04:00
Eine Route kann mittels <tt>pass</tt> zu der nächsten passenden Route springen:
2010-01-01 10:13:42 -05:00
2010-09-10 10:34:41 -04:00
get '/raten/:wer' do
pass unless params[:wer] == 'Frank'
2010-01-01 10:13:42 -05:00
'Du hast mich!'
end
2010-09-10 10:34:41 -04:00
get '/raten/*' do
2010-01-01 10:13:42 -05:00
'Du hast mich verfehlt!'
end
Der Block wird sofort verlassen und es wird nach der nächsten treffenden Route
2010-07-01 01:32:20 -04:00
gesucht. Ein 404 Fehler wird zurückgegeben, wenn kein treffendes Routen-Muster
2010-01-01 10:13:42 -05:00
gefunden wird.
== Konfiguration
2010-09-10 10:34:41 -04:00
Wird einmal beim Starten in jedweder Umgebung ausgeführt:
2010-01-01 10:13:42 -05:00
configure do
...
end
2010-09-29 14:14:06 -04:00
Läuft nur, wenn die Umgebung (RACK_ENV Umgebungsvariable) auf
2010-09-10 10:34:41 -04:00
<tt>:production</tt> gesetzt ist:
2010-01-01 10:13:42 -05:00
configure :production do
...
end
2010-09-29 14:14:06 -04:00
Läuft nur, wenn die Umgebung auf <tt>:production</tt> oder auf <tt>:test</tt>
2010-01-01 10:13:42 -05:00
gesetzt ist:
configure :production, :test do
...
end
2010-09-10 10:34:41 -04:00
== Fehlerbehandlung
2010-01-01 10:13:42 -05:00
2010-09-10 10:34:41 -04:00
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.
2010-01-01 10:13:42 -05:00
=== Nicht gefunden
2010-09-29 14:14:06 -04:00
Wenn eine <tt>Sinatra::NotFound</tt> Exception geworfen wird oder der Statuscode 404 ist, wird der <tt>not_found</tt> Handler ausgeführt:
2010-01-01 10:13:42 -05:00
not_found do
2010-09-29 14:14:06 -04:00
'Seite kann nirgendwo gefunden werden.'
2010-01-01 10:13:42 -05:00
end
=== Fehler
2010-09-29 14:14:06 -04:00
Der +error+ Handler wird immer ausgeführt, wenn eine Exception in einem Routenblock
oder in einen Filter geworfen wurde. Die Exception kann über die
2010-09-10 10:34:41 -04:00
<tt>sinatra.error</tt> Rack-Variable angesprochen werden:
2010-01-01 10:13:42 -05:00
error do
'Entschuldige es gab einen hässlichen Fehler - ' + env['sinatra.error'].name
end
Benutzerdefinierte Fehler:
2010-09-29 14:14:06 -04:00
error MeinFehler do
2010-01-01 10:13:42 -05:00
'Was passiert ist...' + request.env['sinatra.error'].message
end
Dann, wenn das passiert:
get '/' do
2010-09-29 14:14:06 -04:00
raise MeinFehler, 'etwas schlechtes'
2010-01-01 10:13:42 -05:00
end
Bekommt man dieses:
Was passiert ist... etwas schlechtes
2010-09-10 10:34:41 -04:00
Alternativ kann ein Error Handler auch für Statuscode definiert werden:
2010-01-01 10:13:42 -05:00
error 403 do
'Zugriff verboten'
end
get '/geheim' do
403
end
2010-09-10 10:34:41 -04:00
Oder ein Statuscode-Bereich:
2010-01-01 10:13:42 -05:00
error 400..510 do
'Boom'
end
2010-09-10 10:34:41 -04:00
Sinatra setzt verschiedene <tt>not_found</tt> und <tt>error</tt>
2010-01-01 10:13:42 -05:00
Handler in der Development Umgebung.
2010-09-10 10:34:41 -04:00
== Mime-Types
2010-01-01 10:13:42 -05:00
2010-09-10 10:34:41 -04:00
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:
2010-01-01 10:13:42 -05:00
mime_type :foo, 'text/foo'
2010-09-10 10:34:41 -04:00
Es kann aber auch der +content_type+ Helfer verwendet werden:
2010-01-01 10:13:42 -05:00
content_type :foo
== Rack Middleware
2010-09-29 14:14:06 -04:00
Sinatra baut auf Rack[http://rack.rubyforge.org/], einem minimalen Standardinterface für Ruby Webframeworks. Eines der interessantesten
2010-09-10 10:34:41 -04:00
Features für Entwickler ist der Support von Middleware, die
zwischen den Server und die Anwendung geschaltet wird und so HTTP
2010-09-29 14:14:06 -04:00
Request und/oder Antwort überwachen und/oder manipulieren kann.
2010-01-01 10:13:42 -05:00
2010-09-10 10:34:41 -04:00
Sinatra macht das erstellen von Middleware-Verkettungen mit der Top-Level
Methode +use+ zu einem Kinderspiel:
2010-01-01 10:13:42 -05:00
require 'sinatra'
2010-09-29 14:14:06 -04:00
require 'meine_middleware'
2010-01-01 10:13:42 -05:00
use Rack::Lint
2010-09-29 14:14:06 -04:00
use MeineMiddleware
2010-01-01 10:13:42 -05:00
get '/hallo' do
'Hallo Welt'
end
2010-09-29 14:14:06 -04:00
Die Semantik von +use+ entspricht der gleichnamigen Methode der
2010-01-01 10:13:42 -05:00
Rack::Builder[http://rack.rubyforge.org/doc/classes/Rack/Builder.html] DSL
2010-09-10 10:34:41 -04:00
(meist verwendet in Rackup-Dateien). Ein Beispiel dafür ist, dass die
+use+-Methode mehrere/verschiedene Argumente und auch Blöcke entgegen nimmt:
2010-01-01 10:13:42 -05:00
use Rack::Auth::Basic do |username, password|
2010-09-29 14:14:06 -04:00
username == 'admin' && password == 'geheim'
2010-01-01 10:13:42 -05:00
end
2010-09-29 14:14:06 -04:00
Rack bietet eine Vielzahl von standard Middleware für Logging, Debugging,
2010-09-10 10:34:41 -04:00
URL-Routing, Authentifizierung und Session-Verarbeitung.
Sinatra verwendet viele von diesen Komponenten automatisch, abhängig von der
2010-09-29 14:14:06 -04:00
Konfiguration. So muss man häufig +use+ nicht explizit verwenden.
2010-01-01 10:13:42 -05:00
== Testen
2010-09-10 10:34:41 -04:00
Sinatra Tests können mit jedem auf Rack aufbauendem Test Framework geschrieben
werden. {Rack::Test}[http://gitrdoc.com/brynary/rack-test] wird empfohlen:
2010-01-01 10:13:42 -05:00
require 'my_sinatra_app'
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
2010-09-10 10:34:41 -04:00
Klasse werden seit Version 0.9.2 nicht mehr unterstützt.
2010-01-01 10:13:42 -05:00
== Sinatra::Base - Middleware, Bibliotheken, und modulare Anwendungen
2010-09-29 14:14:06 -04:00
Das Definitieren einer Top-Level Anwendung funktioniert gut für
Microanwendungen, hat aber Nachteile, wenn man wiederverwendbare Komponenten
2010-09-10 10:34:41 -04:00
wie Middleware, Rails Metal, einfache Bibliotheken mit Server Komponenten
2010-01-01 10:13:42 -05:00
oder auch Sinatra Erweiterungen bauen will.
2010-09-29 14:14:06 -04:00
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:
2010-01-01 10:13:42 -05:00
require 'sinatra/base'
class MyApp < Sinatra::Base
set :sessions, true
set :foo, 'bar'
get '/' do
'Hallo Welt!'
end
end
2010-09-29 14:14:06 -04:00
Die MyApp-Klasse ist eine unabhängige Rack-Komponente, die als Middleware,
2010-09-10 10:34:41 -04:00
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:
2010-01-01 10:13:42 -05:00
MyApp.run! :host => 'localhost', :port => 9090
2010-09-10 10:34:41 -04:00
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:
2010-01-01 10:13:42 -05:00
2010-09-10 10:34:41 -04:00
* Die Datei sollte <tt>require 'sinatra/base'</tt> anstelle von
<tt>require 'sinatra/base'</tt> aufrufen, ansonsten werden alle von
2010-09-29 14:14:06 -04:00
Sinatras DSL Methoden in den Top-Level- Namespace importiert.
2010-09-10 10:34:41 -04:00
* Alle Routen, Error Handler, Filter und Optionen der Applikation müssen in
2010-09-29 14:14:06 -04:00
einer Subklasse von Sinatra::Base definiert werden.
2010-01-01 10:13:42 -05:00
2010-09-29 14:14:06 -04:00
+Sinatra::Base+ 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.
2010-01-01 10:13:42 -05:00
2010-09-10 10:34:41 -04:00
SIDEBAR: Sinatras Top-Level DSL-Methoden sind als einfache Delegationen
implementiert. Die Sinatra::Application-Klasse -- eine spezielle Subklasse von
Sinatra::Base -- erhält alle :get, :put, :post, :delete, :before, :error,
2010-09-29 14:14:06 -04:00
:not_found, :configure und :set Meldungen, die vom Top-Level aus gesendet
2010-09-10 10:34:41 -04:00
werden. 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].
2010-01-01 10:13:42 -05:00
== Kommandozeile
2010-09-29 14:14:06 -04:00
Sinatra Anwendungen können direkt von der Kommandozeile aus gestartet werden:
2010-01-01 10:13:42 -05:00
ruby myapp.rb [-h] [-x] [-e ENVIRONMENT] [-p PORT] [-h HOST] [-s HANDLER]
2010-09-10 10:34:41 -04:00
Die Optionen sind:
2010-01-01 10:13:42 -05:00
-h # Hilfe
2010-09-29 14:14:06 -04:00
-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)
2010-01-01 10:13:42 -05:00
2010-09-10 10:34:41 -04:00
== Der neueste Stand (The Bleeding Edge)
2010-01-01 10:13:42 -05:00
2010-09-10 10:34:41 -04:00
Um auf den neuesten Stand von Sinatras Code zu sein, kann eine lokale Kopie
2010-01-01 10:13:42 -05:00
angelegt werden. Gestartet wird in der Anwendung mit dem <tt>sinatra/lib</tt>
2010-09-10 10:34:41 -04:00
Ordner im <tt>LOAD_PATH</tt>:
2010-01-01 10:13:42 -05:00
cd myapp
git clone git://github.com/sinatra/sinatra.git
ruby -Isinatra/lib myapp.rb
2010-09-10 10:34:41 -04:00
Alternativ kann der <tt>sinatra/lib</tt> Ordner zum <tt>LOAD_PATH</tt> in
2010-01-01 10:13:42 -05:00
der Anwendung hinzugefügt werden:
$LOAD_PATH.unshift File.dirname(__FILE__) + '/sinatra/lib'
require 'rubygems'
require 'sinatra'
get '/ueber' do
2010-09-29 14:14:06 -04:00
"Ich laufe auf Version " + Sinatra::VERSION
2010-01-01 10:13:42 -05:00
end
2010-09-29 14:14:06 -04:00
Um Sinatra Code von Zeit zu Zeit zu aktualisieren:
2010-01-01 10:13:42 -05:00
cd myproject/sinatra
git pull
== Mehr
* {Projekt Website}[http://sinatra.github.com/] - Ergänzende Dokumentation,
News und Links zu anderen Ressourcen.
2010-09-10 10:34:41 -04:00
* {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]
2010-01-01 10:13:42 -05:00
* {Twitter}[http://twitter.com/sinatra]
2010-09-10 10:34:41 -04:00
* {Mailingliste}[http://groups.google.com/group/sinatrarb]
2010-01-01 10:13:42 -05:00
* {IRC: #sinatra}[irc://chat.freenode.net/#sinatra] auf http://freenode.net