2010-01-01 10:13:42 -05:00
|
|
|
|
= Sinatra
|
2011-03-18 11:11:34 -04:00
|
|
|
|
|
2011-02-21 03:36:31 -05:00
|
|
|
|
<i>Wichtig: Dieses Dokument ist eine Übersetzung aus dem Englischen und unter
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Umständen nicht auf dem aktuellen 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
|
2011-03-17 13:53:27 -04:00
|
|
|
|
mit minimalem Aufwand ermöglicht:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
# myapp.rb
|
|
|
|
|
require 'sinatra'
|
|
|
|
|
get '/' do
|
|
|
|
|
'Hallo Welt!'
|
|
|
|
|
end
|
|
|
|
|
|
2011-02-21 03:34:13 -05: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
|
|
|
|
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Es wird empfohlen, den Thin-Server via <tt>gem install thin</tt> zu
|
|
|
|
|
installieren, den Sinatra dann, soweit vorhanden, automatisch verwendet.
|
|
|
|
|
|
2010-01-01 10:13:42 -05:00
|
|
|
|
== Routen
|
|
|
|
|
|
2011-02-21 03:36:31 -05:00
|
|
|
|
In Sinatra wird eine Route durch eine HTTP-Methode und ein URL-Muster
|
2011-03-06 18:21:13 -05:00
|
|
|
|
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
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
options '/' do
|
2011-05-19 14:30:11 -04:00
|
|
|
|
.. zeige, was wir können ..
|
2011-02-19 20:37:22 -05:00
|
|
|
|
end
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
2010-09-25 17:57:23 -04:00
|
|
|
|
Die Routen werden in der Reihenfolge durchlaufen, in der sie definiert wurden.
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Das erste Routen-Muster, 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
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Man kann auf diese auch mit Block-Parametern zugreifen:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
get '/hallo/:name' do |n|
|
|
|
|
|
"Hallo #{n}!"
|
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Routen-Muster können auch mit Splat- oder Wildcard-Parametern über das
|
|
|
|
|
<tt>params[:splat]</tt>-Array angesprochen werden:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
2011-05-19 14:30:11 -04:00
|
|
|
|
Oder mit Block-Parametern:
|
|
|
|
|
|
|
|
|
|
get '/download/*.*' do |pfad, endung|
|
|
|
|
|
[pfad, endung] # => ["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
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Und auch hier können Block-Parameter genutzt werden:
|
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
|
2011-03-17 13:53:27 -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
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Es können auch andere Bedingungen relativ einfach hinzugefügt werden:
|
2010-09-10 10:34:41 -04:00
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Durch den Rückgabewert eines Routen-Blocks wird mindestens der Response-Body
|
2011-03-18 11:11:34 -04:00
|
|
|
|
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: <tt>[Status (Fixnum), Headers (Hash),
|
|
|
|
|
Response-Body (antwortet auf #each)]</tt>.
|
|
|
|
|
* Ein Array mit zwei Elementen: <tt>[Status (Fixnum), Response-Body (antwortet
|
|
|
|
|
auf #each)]</tt>.
|
|
|
|
|
* Ein Objekt, das auf <tt>#each</tt> antwortet und den an diese Methode
|
|
|
|
|
übergebenen Block nur mit Strings als Übergabewerte aufruft.
|
2011-03-17 13:53:27 -04:00
|
|
|
|
* Ein Fixnum, das den Status-Code festlegt.
|
2010-09-10 10:34:41 -04:00
|
|
|
|
|
|
|
|
|
Damit lässt sich relativ einfach Streaming implementieren:
|
|
|
|
|
|
|
|
|
|
class Stream
|
|
|
|
|
def each
|
|
|
|
|
100.times { |i| yield "#{i}\n" }
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
get('/') { Stream.new }
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
=== Eigene Routen-Muster
|
2011-03-18 11:11:34 -04:00
|
|
|
|
|
2011-03-06 18:21:13 -05:00
|
|
|
|
Wie oben schon beschrieben, ist Sinatra von Haus aus mit Unterstützung für
|
2011-03-17 13:53:27 -04:00
|
|
|
|
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:
|
2011-03-06 18:21:13 -05:00
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Beachte, dass das obige Beispiel etwas übertrieben wirkt. Es geht auch
|
|
|
|
|
einfacher:
|
2011-03-06 18:21:13 -05:00
|
|
|
|
|
|
|
|
|
get // do
|
|
|
|
|
pass if request.path_info == "/index"
|
|
|
|
|
# ...
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
Oder unter Verwendung eines negativen look ahead:
|
|
|
|
|
|
|
|
|
|
get %r{^(?!/index$)} do
|
|
|
|
|
# ...
|
|
|
|
|
end
|
|
|
|
|
|
2010-01-01 10:13:42 -05:00
|
|
|
|
== Statische Dateien
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Statische Dateien werden aus dem <tt>./public</tt>-Ordner ausgeliefert. Es ist
|
2011-06-15 18:24:27 -04:00
|
|
|
|
möglich, einen anderen Ort zu definieren, indem man die
|
|
|
|
|
<tt>:public_folder</tt>-Option setzt:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
2011-06-15 18:24:27 -04:00
|
|
|
|
set :public_folder, File.dirname(__FILE__) + '/static'
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
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
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
Um den <tt>Cache-Control</tt>-Header mit Informationen zu versorgen, verwendet
|
|
|
|
|
man die <tt>:static_cache_control</tt>-Einstellung (s.u.).
|
|
|
|
|
|
2011-03-17 13:53:27 -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
|
2011-03-17 13:53:27 -04:00
|
|
|
|
<tt>./views</tt>-Ordner befinden. Es kann jedoch ein anderer Ordner festgelegt
|
|
|
|
|
werden:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
set :views, File.dirname(__FILE__) + '/templates'
|
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Es ist zu beachten, dass immer mit Symbolen auf Templates verwiesen werden
|
|
|
|
|
muss, auch dann, wenn sie sich in einem Unterordner befinden:
|
2010-09-10 10:34:41 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
haml :'unterverzeichnis/template'
|
2010-09-10 10:34:41 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Rendering-Methoden rendern jeden String direkt.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== Verfügbare Templatesprachen
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Einige Sprachen haben mehrere Implementierungen. Um festzulegen, welche
|
|
|
|
|
verwendet wird (und dann auch Thread-sicher ist), verwendet man am besten zu
|
|
|
|
|
Beginn ein 'require':
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
require 'rdiscount' # oder require 'bluecloth'
|
|
|
|
|
get('/') { markdown :index }
|
2011-03-06 18:21:13 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== Haml Templates
|
2010-09-11 08:52:55 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {haml}[http://haml-lang.com/]
|
|
|
|
|
Dateierweiterungs:: <tt>.haml</tt>
|
|
|
|
|
Beispiel:: <tt>haml :index, :format => :html5</tt>
|
2010-09-11 08:52:55 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== Erb Templates
|
2010-09-11 08:52:55 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {erubis}[http://www.kuwata-lab.com/erubis/] oder
|
|
|
|
|
erb (included in Ruby)
|
|
|
|
|
Dateierweiterungs:: <tt>.erb</tt>, <tt>.rhtml</tt> oder <tt>.erubis</tt>
|
|
|
|
|
(nur Erubis)
|
|
|
|
|
Beispiel:: <tt>erb :index</tt>
|
2010-09-11 08:52:55 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== Builder Templates
|
2010-09-11 08:52:55 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {builder}[http://builder.rubyforge.org/]
|
|
|
|
|
Dateierweiterungs:: <tt>.builder</tt>
|
|
|
|
|
Beispiel:: <tt>builder { |xml| xml.em "Hallo" }</tt>
|
2010-09-11 08:52:55 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Nimmt ebenso einen Block für Inline-Templates entgegen (siehe Beispiel).
|
2010-09-11 08:52:55 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== Nokogiri Templates
|
2010-09-11 08:52:55 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {nokogiri}[http://nokogiri.org/]
|
|
|
|
|
Dateierweiterungs:: <tt>.nokogiri</tt>
|
|
|
|
|
Beispiel:: <tt>nokogiri { |xml| xml.em "Hallo" }</tt>
|
2010-09-11 08:52:55 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Nimmt ebenso einen Block für Inline-Templates entgegen (siehe Beispiel).
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== Sass Templates
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {sass}[http://sass-lang.com/]
|
|
|
|
|
Dateierweiterungs:: <tt>.sass</tt>
|
|
|
|
|
Beispiel:: <tt>sass :stylesheet, :style => :expanded</tt>
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== SCSS Templates
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {sass}[http://sass-lang.com/]
|
|
|
|
|
Dateierweiterungs:: <tt>.scss</tt>
|
|
|
|
|
Beispiel:: <tt>scss :stylesheet, :style => :expanded</tt>
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== Less Templates
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {less}[http://www.lesscss.org/]
|
|
|
|
|
Dateierweiterungs:: <tt>.less</tt>
|
|
|
|
|
Beispiel:: <tt>less :stylesheet</tt>
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== Liquid Templates
|
2010-09-12 07:59:00 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {liquid}[http://www.liquidmarkup.org/]
|
|
|
|
|
Dateierweiterungs:: <tt>.liquid</tt>
|
|
|
|
|
Beispiel:: <tt>liquid :index, :locals => { :key => 'Wert' }</tt>
|
2010-09-12 07:59:00 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
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.
|
2010-09-12 07:59:00 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== Markdown Templates
|
2010-09-12 07:59:00 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {rdiscount}[https://github.com/rtomayko/rdiscount],
|
|
|
|
|
{redcarpet}[https://github.com/tanoku/redcarpet],
|
|
|
|
|
{bluecloth}[http://deveiate.org/projects/BlueCloth],
|
|
|
|
|
{kramdown}[http://kramdown.rubyforge.org/] *oder*
|
|
|
|
|
{maruku}[http://maruku.rubyforge.org/]
|
|
|
|
|
Dateierweiterungs:: <tt>.markdown</tt>, <tt>.mkd</tt> und <tt>.md</tt>
|
|
|
|
|
Beispiel:: <tt>markdown :index, :layout_engine => :erb</tt>
|
2010-09-12 07:59:00 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
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:
|
2010-09-12 07:59:00 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
erb :overview, :locals => { :text => markdown(:einfuehrung) }
|
2010-09-12 07:59:00 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Beachte, dass man die +markdown+-Methode auch aus anderen Templates heraus
|
|
|
|
|
aufrufen kann:
|
2010-09-12 07:59:00 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
%h1 Gruß von Haml!
|
|
|
|
|
%p= markdown(:Grüsse)
|
2010-09-12 07:59:00 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
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
|
|
|
|
|
<tt>:layout_engine</tt>-Option verwendet wird.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== Textile Templates
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {RedCloth}[http://redcloth.org/]
|
|
|
|
|
Dateierweiterungs:: <tt>.textile</tt>
|
|
|
|
|
Beispiel:: <tt>textile :index, :layout_engine => :erb</tt>
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
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:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
erb :overview, :locals => { :text => textile(:einfuehrung) }
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Beachte, dass man die +textile+-Methode auch aus anderen Templates heraus
|
|
|
|
|
aufrufen kann:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
%h1 Gruß von Haml!
|
|
|
|
|
%p= textile(:Grüsse)
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
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
|
|
|
|
|
<tt>:layout_engine</tt>-Option verwendet wird.
|
2010-09-12 09:14:45 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== RDoc Templates
|
2010-09-12 09:14:45 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {rdoc}[http://rdoc.rubyforge.org/]
|
|
|
|
|
Dateierweiterungs:: <tt>.rdoc</tt>
|
|
|
|
|
Beispiel:: <tt>textile :README, :layout_engine => :erb</tt>
|
2010-09-12 09:14:45 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
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:
|
2010-09-12 09:14:45 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
erb :overview, :locals => { :text => rdoc(:einfuehrung) }
|
2010-09-12 09:14:45 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Beachte, dass man die +rdoc+-Methode auch aus anderen Templates heraus
|
|
|
|
|
aufrufen kann:
|
2010-09-12 11:00:33 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
%h1 Gruß von Haml!
|
|
|
|
|
%p= rdoc(:Grüße)
|
2010-11-05 08:59:49 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
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
|
|
|
|
|
<tt>:layout_engine</tt>-Option verwendet wird.
|
2010-11-05 08:59:49 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== Radius Templates
|
2010-11-05 08:59:49 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {radius}[http://radius.rubyforge.org/]
|
|
|
|
|
Dateierweiterungs:: <tt>.radius</tt>
|
|
|
|
|
Beispiel:: <tt>radius :index, :locals => { :key => 'Wert' }</tt>
|
2010-11-05 08:59:49 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Da man aus dem Radius-Template heraus keine Ruby-Methoden aufrufen kann, wird
|
|
|
|
|
man üblicherweise locals verwenden wollen, mit denen man Variablen weitergibt.
|
2010-11-05 08:59:49 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== Markaby Templates
|
2010-09-12 11:00:33 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {markaby}[http://markaby.github.com/]
|
|
|
|
|
Dateierweiterungs:: <tt>.mab</tt>
|
|
|
|
|
Beispiel:: <tt>markaby { h1 "Willkommen!" }</tt>
|
2011-04-15 05:51:35 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Nimmt ebenso einen Block für Inline-Templates entgegen (siehe Beispiel).
|
2011-04-15 05:51:35 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== Slim Templates
|
2011-04-15 05:51:35 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {slim}[http://slim-lang.com/]
|
|
|
|
|
Dateierweiterungs:: <tt>.slim</tt>
|
|
|
|
|
Beispiel:: <tt>slim :index</tt>
|
2011-04-15 05:51:35 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== Creole Templates
|
2011-04-15 05:51:35 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {creole}[https://github.com/minad/creole]
|
|
|
|
|
Dateierweiterungs:: <tt>.creole</tt>
|
|
|
|
|
Beispiel:: <tt>creole :wiki, :layout_engine => :erb</tt>
|
2010-09-12 17:09:10 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
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:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
erb :overview, :locals => { :text => creole(:einfuehrung) }
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Beachte, dass man die +creole+-Methode auch aus anderen Templates heraus
|
|
|
|
|
aufrufen kann:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
%h1 Gruß von Haml!
|
|
|
|
|
%p= creole(:Grüße)
|
2010-09-12 17:09:10 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
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
|
|
|
|
|
<tt>:layout_engine</tt>-Option verwendet wird.
|
2010-09-12 17:09:10 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== CoffeeScript Templates
|
2010-09-12 17:09:10 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Abhängigkeit:: {coffee-script}[https://github.com/josh/ruby-coffee-script]
|
|
|
|
|
und eine {Möglichkeit JavaScript auszuführen}[https://github.com/sstephenson/execjs/blob/master/README.md#readme]
|
|
|
|
|
Dateierweiterungs:: <tt>.coffee</tt>
|
|
|
|
|
Beispiel:: <tt>coffee :index</tt>
|
2010-09-12 17:09:10 -04:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
=== Eingebettete Templates
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
|
haml '%div.title Hallo Welt'
|
|
|
|
|
end
|
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Rendert den eingebetteten Template-String.
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
=== Auf Variablen in Templates zugreifen
|
|
|
|
|
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Templates werden in demselben 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])
|
2011-05-19 14:30:11 -04:00
|
|
|
|
haml '%h1= bar.name', :locals => { :bar => foo }
|
2010-01-01 10:13:42 -05:00
|
|
|
|
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!!!!!
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Anmerkung: Inline-Templates, die in der Datei definiert sind, die <tt>require
|
2010-09-29 14:14:06 -04:00
|
|
|
|
'sinatra'</tt> aufruft, werden automatisch geladen. Um andere Inline-Templates
|
2011-03-17 13:53:27 -04:00
|
|
|
|
in anderen Dateien aufzurufen, muss explizit <tt>enable :inline_templates</tt>
|
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
|
2011-03-18 11:11:34 -04:00
|
|
|
|
verwendet. Durch <tt>:layout => false</tt> kann das Ausführen verhindert
|
|
|
|
|
werden:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
get '/' do
|
2011-05-19 14:30:11 -04:00
|
|
|
|
haml :index, :layout => request.xhr?
|
2010-01-01 10:13:42 -05:00
|
|
|
|
end
|
|
|
|
|
|
2011-03-06 18:21:13 -05:00
|
|
|
|
=== Dateiendungen zuordnen
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Um eine Dateiendung einer Template-Engine zuzuordnen, kann
|
|
|
|
|
<tt>Tilt.register</tt> genutzt werden. Wenn etwa die Dateiendung +tt+ für
|
|
|
|
|
Textile-Templates genutzt werden soll, lässt sich dies wie folgt
|
|
|
|
|
bewerkstelligen:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
Tilt.register :tt, Tilt[:textile]
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
=== Eine eigene Template-Engine hinzufügen
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Zu allererst muss die Engine bei Tilt registriert und danach eine
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Rendering-Methode erstellt werden:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-02-20 04:08:14 -05:00
|
|
|
|
Tilt.register :mtt, MeineTolleTemplateEngine
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
helpers do
|
2011-02-20 04:08:14 -05:00
|
|
|
|
def mtt(*args) render(:mtt, *args) end
|
2010-01-01 10:13:42 -05:00
|
|
|
|
end
|
|
|
|
|
|
2011-02-19 20:37:22 -05:00
|
|
|
|
get '/' do
|
2011-02-20 04:08:14 -05:00
|
|
|
|
mtt :index
|
2010-01-01 10:13:42 -05:00
|
|
|
|
end
|
|
|
|
|
|
2011-02-20 04:08:14 -05:00
|
|
|
|
Dieser Code rendert <tt>./views/application.mtt</tt>. Siehe
|
2011-03-18 11:11:34 -04:00
|
|
|
|
github.com/rtomayko/tilt[https://github.com/rtomayko/tilt], um mehr über Tilt
|
|
|
|
|
zu lernen.
|
|
|
|
|
|
2010-01-01 10:13:42 -05:00
|
|
|
|
== Filter
|
|
|
|
|
|
2011-03-18 11:11:34 -04:00
|
|
|
|
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.
|
2011-03-17 13:53:27 -04:00
|
|
|
|
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
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
After-Filter werden nach jedem Request in demselben Kontext ausgeführt und
|
2010-09-10 10:34:41 -04:00
|
|
|
|
können ebenfalls Request und Antwort ändern. In Before-Filtern gesetzte
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Instanzvariablen können in After-Filtern verwendet werden:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
after do
|
|
|
|
|
puts response.status
|
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Filter können optional auch mit einem Muster ausgestattet werden, welches auf
|
|
|
|
|
den Request-Pfad passen muss, 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
|
|
|
|
|
|
2011-02-19 20:37:22 -05:00
|
|
|
|
Ähnlich wie Routen können Filter auch mit weiteren Bedingungen eingeschränkt
|
|
|
|
|
werden:
|
2010-11-03 08:51:52 -04:00
|
|
|
|
|
|
|
|
|
before :agent => /Songbird/ do
|
|
|
|
|
# ...
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
after '/blog/*', :host_name => 'example.com' do
|
|
|
|
|
# ...
|
|
|
|
|
end
|
|
|
|
|
|
2011-02-19 20:37:22 -05:00
|
|
|
|
== Helfer
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Durch die Top-Level <tt>helpers</tt>-Methode werden sogenannte Helfer-Methoden
|
2011-02-19 20:37:22 -05:00
|
|
|
|
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
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
=== Sessions verwenden
|
2011-03-06 18:21:13 -05:00
|
|
|
|
Sessions werden verwendet, um Zustände zwischen den Requests zu speichern.
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Sind sie aktiviert, kann ein Session-Hash je Benutzer-Session verwendet werden.
|
2011-03-06 18:21:13 -05:00
|
|
|
|
|
|
|
|
|
enable :sessions
|
|
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
|
"value = " << session[:value].inspect
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
get '/:value' do
|
|
|
|
|
session[:value] = params[:value]
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
Beachte, dass <tt>enable :sessions</tt> alle Daten in einem Cookie speichert.
|
|
|
|
|
Unter Umständen kann dies negative Effekte haben, z.B. verursachen viele Daten
|
2011-03-17 13:53:27 -04:00
|
|
|
|
höheren, teilweise überflüssigen Traffic. Um das zu vermeiden, kann eine Rack-
|
|
|
|
|
Session-Middleware verwendet werden. Dabei wird auf <tt>enable :sessions</tt>
|
|
|
|
|
verzichtet und die Middleware wie üblich im Programm eingebunden:
|
2011-03-06 18:21:13 -05:00
|
|
|
|
|
|
|
|
|
use Rack::Session::Pool, :expire_after => 2592000
|
|
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
|
"value = " << session[:value].inspect
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
get '/:value' do
|
|
|
|
|
session[:value] = params[:value]
|
|
|
|
|
end
|
|
|
|
|
|
2011-03-15 13:21:59 -04:00
|
|
|
|
Um die Sicherheit zu erhöhen, werden Cookies, die Session-Daten führen, mit
|
2011-03-17 13:53:27 -04:00
|
|
|
|
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:
|
2011-03-14 18:23:32 -04:00
|
|
|
|
|
|
|
|
|
set :session_secret, 'super secret'
|
2011-03-06 18:21:13 -05:00
|
|
|
|
|
2011-04-01 15:52:48 -04:00
|
|
|
|
Zur weiteren Konfiguration kann man einen Hash mit Optionen in den +sessions+
|
|
|
|
|
Einstellungen ablegen.
|
|
|
|
|
|
|
|
|
|
set :sessions, :domain => 'foo.com'
|
|
|
|
|
|
2010-01-01 10:13:42 -05:00
|
|
|
|
== Anhalten
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Zum sofortigen Stoppen eines Request in einem Filter oder einer Route:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
halt
|
|
|
|
|
|
2011-03-17 13:53:27 -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!'
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Sogar mit Headern:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
halt 402, {'Content-Type' => 'text/plain'}, 'Rache'
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Natürlich ist es auch möglich, ein Template mit +halt+ zu verwenden:
|
2011-03-06 18:21:13 -05:00
|
|
|
|
|
|
|
|
|
halt erb(:error)
|
|
|
|
|
|
2010-01-01 10:13:42 -05:00
|
|
|
|
== 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
|
2011-03-18 11:11:34 -04:00
|
|
|
|
'Du hast mich nicht!'
|
2010-01-01 10:13:42 -05:00
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
Der Block wird sofort verlassen und es wird nach der nächsten treffenden Route
|
2011-03-17 13:53:27 -04:00
|
|
|
|
gesucht. Ein 404-Fehler wird zurückgegeben, wenn kein treffendes Routen-Muster
|
2010-01-01 10:13:42 -05:00
|
|
|
|
gefunden wird.
|
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
=== Eine andere Route ansteuern
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-02-21 03:36:31 -05:00
|
|
|
|
Manchmal entspricht +pass+ nicht den Anforderungen, wenn das Ergebnis einer
|
2011-02-21 03:34:13 -05:00
|
|
|
|
anderen Route gefordert wird. Um das zu erreichen, lässt sich +call+ nutzen:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
get '/foo' do
|
2011-04-17 06:43:22 -04:00
|
|
|
|
status, headers, body = call env.merge("PATH_INFO" => '/bar')
|
2011-04-17 06:56:03 -04:00
|
|
|
|
[status, headers, body.map(&:upcase)]
|
2011-02-19 20:37:22 -05:00
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
get '/bar' do
|
|
|
|
|
"bar"
|
|
|
|
|
end
|
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
Beachte, dass in dem oben angegeben Beispiel die Performance erheblich erhöht
|
2011-03-18 11:11:34 -04:00
|
|
|
|
werden kann, wenn <tt>"bar"</tt> in eine Helfer-Methode umgewandelt wird, auf
|
|
|
|
|
die <tt>/foo</tt> und <tt>/bar</tt> zugreifen können.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Wenn der Request innerhalb derselben Applikations-Instanz aufgerufen und keine
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Kopie der Instanz erzeugt werden soll, kann <tt>call!</tt> anstelle von
|
2011-03-17 13:53:27 -04:00
|
|
|
|
+call+ verwendet werden.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Die Rack-Spezifikationen enthalten weitere Informationen zu +call+.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
=== Body, Status-Code und Header setzen
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Es ist möglich und empfohlen, den Status-Code sowie den Response-Body mit einem
|
2011-02-21 03:34:13 -05:00
|
|
|
|
Returnwert in der Route zu setzen. In manchen Situationen kann es jedoch sein,
|
2011-02-21 03:36:31 -05:00
|
|
|
|
dass der Body an irgendeiner anderen Stelle während der Ausführung gesetzt
|
2011-03-17 13:53:27 -04:00
|
|
|
|
wird. Das lässt sich mit der Helfer-Methode +body+ bewerkstelligen. Wird +body+
|
|
|
|
|
verwendet, lässt sich der Body jederzeit über diese Methode aufrufen:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
get '/foo' do
|
|
|
|
|
body "bar"
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
after do
|
|
|
|
|
puts body
|
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Ebenso ist es möglich, einen Block an +body+ weiterzureichen, der dann vom
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Rack-Handler ausgeführt wird (lässt sich z.B. zur Umsetzung von Streaming
|
|
|
|
|
einsetzen, siehe auch "Rückgabewerte").
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Vergleichbar mit +body+ lassen sich auch Status-Code und Header setzen:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
get '/foo' do
|
|
|
|
|
status 418
|
2011-02-21 03:49:10 -05:00
|
|
|
|
headers \
|
2011-08-09 06:26:53 -04:00
|
|
|
|
"Allow" => "BREW, POST, GET, PROPFIND, WHEN",
|
2011-02-21 03:49:10 -05:00
|
|
|
|
"Refresh" => "Refresh: 20; http://www.ietf.org/rfc/rfc2324.txt"
|
2011-02-21 03:34:13 -05:00
|
|
|
|
halt "Ich bin ein Teekesselchen"
|
2011-02-19 20:37:22 -05:00
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Genau wie bei +body+ liest ein Aufrufen von +headers+ oder +status+ ohne
|
2011-02-21 03:49:10 -05:00
|
|
|
|
Argumente den aktuellen Wert aus.
|
|
|
|
|
|
2011-04-01 15:52:48 -04:00
|
|
|
|
=== Logger
|
|
|
|
|
|
|
|
|
|
Im Geltungsbereich eines Request stellt die +logger+ Helfer-Methode eine
|
|
|
|
|
+Logger+ Instanz zur Verfügung:
|
|
|
|
|
|
|
|
|
|
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 <tt>Sinatra::Application</tt>
|
|
|
|
|
voreingestellt ist. Wird über <tt>Sinatra::Base</tt> vererbt, muss es erst
|
|
|
|
|
aktiviert werden:
|
|
|
|
|
|
|
|
|
|
class MyApp < Sinatra::Base
|
|
|
|
|
configure(:production, :development) do
|
|
|
|
|
enable :logging
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
|
2011-02-21 03:49:10 -05:00
|
|
|
|
== 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:
|
|
|
|
|
|
2011-05-19 14:30:11 -04:00
|
|
|
|
configure do
|
|
|
|
|
mime_type :foo, 'text/foo'
|
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Es kann aber auch der +content_type+-Helfer verwendet werden:
|
2011-02-21 03:49:10 -05:00
|
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
|
content_type :foo
|
|
|
|
|
"foo foo foo"
|
|
|
|
|
end
|
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
=== URLs generieren
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Zum Generieren von URLs sollte die +url+-Helfer-Methode genutzen werden, so
|
|
|
|
|
z.B. beim Einsatz von Haml:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
%a{:href => url('/foo')} foo
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Soweit vorhanden, wird Rücksicht auf Proxys und Rack-Router genommen.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Diese Methode ist ebenso über das Alias +to+ zu erreichen (siehe Beispiel
|
2011-02-21 03:34:13 -05:00
|
|
|
|
unten).
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
=== Browser-Umleitung
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Eine Browser-Umleitung kann mithilfe der +redirect+-Helfer-Methode erreicht
|
2011-02-21 03:34:13 -05:00
|
|
|
|
werden:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
get '/foo' do
|
|
|
|
|
redirect to('/bar')
|
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Weitere Parameter werden wie Argumente der +halt+-Methode behandelt:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
redirect to('/bar'), 303
|
2011-03-18 11:11:34 -04:00
|
|
|
|
redirect 'http://google.com', 'Hier bist du falsch'
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Ebenso leicht lässt sich ein Schritt zurück mit dem Alias
|
2011-02-21 03:34:13 -05:00
|
|
|
|
<tt>redirect back</tt> erreichen:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
get '/foo' do
|
2011-02-21 03:34:13 -05:00
|
|
|
|
"<a href='/bar'>mach was</a>"
|
2011-02-19 20:37:22 -05:00
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
get '/bar' do
|
2011-02-21 03:34:13 -05:00
|
|
|
|
mach_was
|
2011-02-19 20:37:22 -05:00
|
|
|
|
redirect back
|
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Um Argumente an ein Redirect weiterzugeben, können sie entweder dem Query
|
|
|
|
|
übergeben:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
redirect to('/bar?summe=42')
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
oder eine Session verwendet werden:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-08-23 06:49:23 -04:00
|
|
|
|
enable :sessions
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
get '/foo' do
|
|
|
|
|
session[:secret] = 'foo'
|
|
|
|
|
redirect to('/bar')
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
get '/bar' do
|
|
|
|
|
session[:secret]
|
|
|
|
|
end
|
|
|
|
|
|
2011-04-19 15:47:21 -04:00
|
|
|
|
|
|
|
|
|
=== Cache einsetzen
|
|
|
|
|
|
2011-04-19 16:29:40 -04:00
|
|
|
|
Ein sinnvolles Einstellen von Header-Daten ist die Grundlage für ein
|
2011-04-19 15:47:21 -04:00
|
|
|
|
ordentliches HTTP-Caching.
|
|
|
|
|
|
|
|
|
|
Der Cache-Control-Header lässt sich ganz einfach einstellen:
|
|
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
|
cache_control :public
|
|
|
|
|
"schon gecached!"
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
Profitipp: Caching im before-Filter aktivieren
|
|
|
|
|
|
|
|
|
|
before do
|
|
|
|
|
cache_control :public, :must_revalidate, :max_age => 60
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
Bei Verwendung der +expires+-Helfermethode zum Setzen des gleichnamigen
|
|
|
|
|
Headers, wird <tt>Cache-Control</tt> automatisch eigestellt:
|
|
|
|
|
|
|
|
|
|
before do
|
|
|
|
|
expires 500, :public, :must_revalidate
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
Um alles richtig zu machen, sollten auch +etag+ und +last_modified+ verwendet
|
|
|
|
|
werden. Es wird empfohlen, dass diese Helfer aufgerufen werden *bevor* die
|
2011-04-19 16:29:40 -04:00
|
|
|
|
eigentliche Arbeit anfängt, da sie sofort eine Antwort senden, wenn der
|
2011-04-19 15:47:21 -04:00
|
|
|
|
Client eine aktuelle Version im Cache vorhält:
|
|
|
|
|
|
|
|
|
|
get '/article/:id' do
|
|
|
|
|
@article = Article.find params[:id]
|
|
|
|
|
last_modified @article.updated_at
|
|
|
|
|
etag @article.sha1
|
|
|
|
|
erb :article
|
|
|
|
|
end
|
|
|
|
|
|
2011-04-19 16:29:40 -04:00
|
|
|
|
ebenso ist es möglich einen
|
2011-04-19 15:47:21 -04:00
|
|
|
|
{schwachen ETag}[http://de.wikipedia.org/wiki/HTTP_ETag] zu verwenden:
|
|
|
|
|
|
|
|
|
|
etag @article.sha1, :weak
|
|
|
|
|
|
|
|
|
|
Diese Helfer führen nicht das eigentliche Caching aus, sondern geben die dafür
|
2011-04-19 16:29:40 -04:00
|
|
|
|
notwendigen Informationen an den Cache weiter. Für schnelle Cache-Lösungen
|
2011-04-19 15:47:21 -04:00
|
|
|
|
bietet sich z.B. {rack-cache}[http://rtomayko.github.com/rack-cache/] an:
|
|
|
|
|
|
|
|
|
|
require "rack/cache"
|
|
|
|
|
require "sinatra"
|
|
|
|
|
|
|
|
|
|
use Rack::Cache
|
|
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
|
cache_control :public, :max_age => 36000
|
|
|
|
|
sleep 5
|
|
|
|
|
"hello"
|
|
|
|
|
end
|
2011-06-09 05:40:24 -04:00
|
|
|
|
|
|
|
|
|
Um den <tt>Cache-Control</tt>-Header mit Informationen zu versorgen, verwendet
|
|
|
|
|
man die <tt>:static_cache_control</tt>-Einstellung (s.u.).
|
2011-04-19 15:47:21 -04:00
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
=== Dateien versenden
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Zum Versenden von Dateien kann die <tt>send_file</tt>-Helfer-Methode verwendet
|
2011-02-21 03:34:13 -05:00
|
|
|
|
werden:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
|
send_file 'foo.png'
|
|
|
|
|
end
|
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
Für <tt>send_file</tt> stehen einige Hash-Optionen zur Verfügung:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
send_file 'foo.png', :type => :jpg
|
|
|
|
|
|
|
|
|
|
[filename]
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Dateiname als Response. Standardwert ist der eigentliche Dateiname.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
[last_modified]
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Wert für den Last-Modified-Header, Standardwert ist +mtime+ der Datei.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
[type]
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Content-Type, der verwendet werden soll. Wird, wenn nicht angegeben, von der
|
2011-02-21 03:34:13 -05:00
|
|
|
|
Dateiendung abgeleitet.
|
|
|
|
|
|
2011-02-19 20:37:22 -05:00
|
|
|
|
[disposition]
|
2011-02-21 03:34:13 -05:00
|
|
|
|
Verwendet für Content-Disposition. Mögliche Werte sind: +nil+ (Standard),
|
2011-03-17 13:53:27 -04:00
|
|
|
|
<tt>:attachment</tt> und <tt>:inline</tt>.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
[length]
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Content-Length-Header. Standardwert ist die Dateigröße.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Soweit vom Rack-Handler unterstützt, werden neben der Übertragung über den
|
|
|
|
|
Ruby-Prozess auch andere Möglichkeiten genutzt. Bei Verwendung der
|
|
|
|
|
<tt>send_file</tt>-Helfer-Methode kümmert sich Sinatra selbstständig um die
|
|
|
|
|
Range-Requests.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2010-10-13 12:59:58 -04:00
|
|
|
|
== Das Request-Objekt
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Auf das +request+-Objekt der eigehenden Anfrage kann vom Anfrage-Scope aus
|
|
|
|
|
zugegriffen werden:
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
|
|
|
|
# App läuft unter http://example.com/example
|
|
|
|
|
get '/foo' do
|
2011-04-01 15:52:48 -04:00
|
|
|
|
t = %w[text/css text/html application/javascript]
|
|
|
|
|
request.accept # ['text/html', '*/*']
|
|
|
|
|
request.accept? 'text/xml' # true
|
|
|
|
|
request.preferred_type(t) # 'text/html'
|
|
|
|
|
request.body # Request-Body des Client (siehe unten)
|
|
|
|
|
request.scheme # "http"
|
|
|
|
|
request.script_name # "/example"
|
|
|
|
|
request.path_info # "/foo"
|
|
|
|
|
request.port # 80
|
|
|
|
|
request.request_method # "GET"
|
|
|
|
|
request.query_string # ""
|
|
|
|
|
request.content_length # Länge des request.body
|
|
|
|
|
request.media_type # Medientypus von request.body
|
|
|
|
|
request.host # "example.com"
|
|
|
|
|
request.get? # true (ähnliche Methoden für andere Verben)
|
|
|
|
|
request.form_data? # false
|
|
|
|
|
request["IRGENDEIN_HEADER"] # Wert von IRGENDEIN_HEADER header
|
|
|
|
|
request.referrer # Der Referrer des Clients oder '/'
|
|
|
|
|
request.user_agent # User-Agent (verwendet in der :agent Bedingung)
|
|
|
|
|
request.cookies # Hash des Browser-Cookies
|
|
|
|
|
request.xhr? # Ist das hier ein Ajax-Request?
|
|
|
|
|
request.url # "http://example.com/example/foo"
|
|
|
|
|
request.path # "/example/foo"
|
|
|
|
|
request.ip # IP-Adresse des Clients
|
|
|
|
|
request.secure? # false (true wenn SSL)
|
|
|
|
|
request.forwarded? # true (Wenn es hinter einem Reverse-Proxy verwendet wird)
|
|
|
|
|
request.env # vollständiger env-Hash von Rack übergeben
|
2010-10-13 12:59:58 -04:00
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Manche Optionen, wie etwa <tt>script_name</tt> oder <tt>path_info</tt>, sind
|
2010-10-13 12:59:58 -04:00
|
|
|
|
auch schreibbar:
|
|
|
|
|
|
|
|
|
|
before { request.path_info = "/" }
|
|
|
|
|
|
|
|
|
|
get "/" do
|
|
|
|
|
"Alle Anfragen kommen hier an!"
|
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Der <tt>request.body</tt> ist ein IO- oder StringIO-Objekt:
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
|
|
|
|
post "/api" do
|
2011-03-17 13:53:27 -04:00
|
|
|
|
request.body.rewind # falls schon jemand davon gelesen hat
|
2010-10-13 12:59:58 -04:00
|
|
|
|
daten = JSON.parse request.body.read
|
|
|
|
|
"Hallo #{daten['name']}!"
|
|
|
|
|
end
|
|
|
|
|
|
2011-03-06 18:21:13 -05:00
|
|
|
|
=== Anhänge
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Damit der Browser erkennt, dass ein Response gespeichert und nicht im Browser
|
|
|
|
|
angezeigt werden soll, kann der +attachment+-Helfer verwendet werden:
|
2011-03-06 18:21:13 -05:00
|
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
|
attachment
|
|
|
|
|
"Speichern!"
|
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Ebenso kann eine Dateiname als Parameter hinzugefügt werden:
|
2011-03-06 18:21:13 -05:00
|
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
|
attachment "info.txt"
|
|
|
|
|
"Speichern!"
|
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
=== Nachschlagen von Template-Dateien
|
2011-02-21 03:34:13 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Die <tt>find_template</tt>-Helfer-Methode wird genutzt, um Template-Dateien zum
|
2011-02-21 03:34:13 -05:00
|
|
|
|
Rendern aufzufinden:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
find_template settings.views, 'foo', Tilt[:haml] do |file|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
puts "könnte diese hier sein: #{file}"
|
2011-02-19 20:37:22 -05:00
|
|
|
|
end
|
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
Das ist zwar nicht wirklich brauchbar, aber wenn man sie überschreibt, kann sie
|
2011-03-17 13:53:27 -04:00
|
|
|
|
nützlich werden, um eigene Nachschlage-Mechanismen einzubauen. Zum Beispiel
|
|
|
|
|
dann, wenn mehr als nur ein view-Verzeichnis verwendet werden soll:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
set :views, ['views', 'templates']
|
|
|
|
|
|
|
|
|
|
helpers do
|
|
|
|
|
def find_template(views, name, engine, &block)
|
|
|
|
|
Array(views).each { |v| super(v, name, engine, &block) }
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Ein anderes Beispiel wäre, verschiedene Vereichnisse für verschiedene Engines
|
2011-02-21 03:34:13 -05:00
|
|
|
|
zu verwenden:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Ebensogut könnte eine Extension aber auch geschrieben und mit anderen geteilt
|
|
|
|
|
werden!
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-02-21 03:36:31 -05:00
|
|
|
|
Beachte, dass <tt>find_template</tt> nicht prüft, ob eine Datei tatsächlich
|
|
|
|
|
existiert. Es wird lediglich der angegebene Block aufgerufen und nach allen
|
2011-03-17 13:53:27 -04:00
|
|
|
|
möglichen Pfaden gesucht. Das ergibt kein Performance-Problem, da +render+
|
2011-02-21 03:36:31 -05:00
|
|
|
|
+block+ verwendet, sobald eine Datei gefunden wurde. Ebenso werden
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Template-Pfade samt Inhalt gecached, solange nicht im Entwicklungsmodus
|
|
|
|
|
gearbeitet wird. Das sollte im Hinterkopf behalten werden, wenn irgendwelche
|
|
|
|
|
verrückten Methoden zusammenbastelt werden.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2010-01-01 10:13:42 -05:00
|
|
|
|
== 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
|
2011-02-19 20:37:22 -05:00
|
|
|
|
# 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
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
# dynamische Einstellungen mit Blöcken
|
2011-02-19 20:37:22 -05:00
|
|
|
|
set(:css_dir) { File.join(views, 'css') }
|
2010-01-01 10:13:42 -05:00
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -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
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Diese Einstellungen sind über +settings+ erreichbar:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
configure do
|
|
|
|
|
set :foo, 'bar'
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
get '/' do
|
|
|
|
|
settings.foo? # => true
|
|
|
|
|
settings.foo # => 'bar'
|
|
|
|
|
...
|
|
|
|
|
end
|
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
=== Mögliche Einstellungen
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[absolute_redirects] 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
|
|
|
|
|
+url+-Helfer-Methode nach wie vor absolute URLs
|
|
|
|
|
erstellen wird, es sei denn, es wird als zweiter
|
|
|
|
|
Parameter +false+ angegeben.
|
|
|
|
|
|
|
|
|
|
Standardmäßig nicht aktiviert.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[add_charsets] Mime-Types werden hier automatisch der Helfer-Methode
|
|
|
|
|
<tt>content_type</tt> zugeordnet.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
Es empfielt sich, Werte hinzuzufügen statt sie zu
|
|
|
|
|
überschreiben:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
settings.add_charsets << "application/foobar"
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[app_file] Hauptdatei der Applikation. Wird verwendet, um das
|
|
|
|
|
Wurzel-, Inline-, View- und öffentliche Verzeichnis des
|
|
|
|
|
Projekts festzustellen.
|
2011-02-21 03:34:13 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[bind] IP-Address, an die gebunden wird
|
|
|
|
|
(Standardwert: 0.0.0.0). Wird nur für den eingebauten
|
|
|
|
|
Server verwendet.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[default_encoding] Das Encoding, falls keines angegeben wurde.
|
|
|
|
|
Standardwert ist <tt>"utf-8"</tt>.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[dump_errors] Fehler im Log anzeigen.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[environment] Momentane Umgebung. Standardmäßig auf
|
|
|
|
|
<tt>content_type</tt> oder <tt>"development"</tt>
|
|
|
|
|
eingestellt, soweit ersteres nicht vorhanden.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[logging] Den Logger verwenden.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[lock] Jeder Request wird gelocked. Es kann nur ein Request
|
|
|
|
|
pro Ruby-Prozess gleichzeitig verarbeitet werden.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
Eingeschaltet, wenn die Applikation threadsicher ist.
|
|
|
|
|
Standardmäßig nicht aktiviert.
|
|
|
|
|
|
|
|
|
|
[method_override] Verwende <tt>_method</tt>, um put/delete-Formulardaten
|
|
|
|
|
in Browsern zu verwenden, die dies normalerweise nicht
|
|
|
|
|
unterstützen.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[port] Port für die Applikation. Wird nur im internen Server
|
|
|
|
|
verwendet.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[prefixed_redirects] 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.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-15 18:24:27 -04:00
|
|
|
|
[public_folder] Das öffentliche Verzeichnis, aus dem Daten zur
|
2011-06-09 05:40:24 -04:00
|
|
|
|
Verfügung gestellt werden können.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[reload_templates] Im development-Modus aktiviert.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[root] Wurzelverzeichnis des Projekts.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[raise_errors] Einen Ausnahmezustand aufrufen. Beendet die
|
|
|
|
|
Applikation.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[run] Wenn aktiviert, wird Sinatra versuchen, den Webserver
|
|
|
|
|
zu starten. Nicht verwenden, wenn Rackup oder anderes
|
|
|
|
|
verwendet werden soll.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[running] Läuft der eingebaute Server? Diese Einstellung nicht
|
|
|
|
|
ändern!
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[server] Server oder Liste von Servern, die als eingebaute
|
|
|
|
|
Server zur Verfügung stehen.
|
|
|
|
|
Standardmäßig auf ['thin', 'mongrel', 'webrick']
|
|
|
|
|
voreingestellt. Die Anordnung gibt die Priorität vor.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[sessions] Sessions auf Cookiebasis aktivieren.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[show_exceptions] Stacktrace im Browser bei Fehlern anzeigen.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[static] 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.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[static_cache_control] Wenn Sinatra statische Daten zur Verfügung stellt,
|
|
|
|
|
können mit dieser Einstellung die +Cache-Control+
|
|
|
|
|
Header zu den Responses hinzugefügt werden. Die
|
|
|
|
|
Einstellung verwendet dazu die +cache_control+
|
|
|
|
|
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>
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-09 05:40:24 -04:00
|
|
|
|
[views] Verzeichnis der Views.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2010-09-10 10:34:41 -04:00
|
|
|
|
== Fehlerbehandlung
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Error-Handler laufen in demselben Kontext wie Routen und Filter, was bedeutet,
|
2010-09-10 10:34:41 -04:00
|
|
|
|
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
|
|
|
|
|
|
2011-03-17 13:53:27 -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
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Der +error+-Handler wird immer ausgeführt, wenn eine Exception in einem
|
|
|
|
|
Routen-Block oder in einem Filter geworfen wurde. Die Exception kann über die
|
|
|
|
|
<tt>sinatra.error</tt>-Rack-Variable angesprochen werden:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
error do
|
2011-03-17 13:53:27 -04:00
|
|
|
|
'Entschuldige, es gab einen hässlichen Fehler - ' + env['sinatra.error'].name
|
2010-01-01 10:13:42 -05:00
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
Benutzerdefinierte Fehler:
|
|
|
|
|
|
2010-09-29 14:14:06 -04:00
|
|
|
|
error MeinFehler do
|
2011-04-17 06:43:22 -04:00
|
|
|
|
'Au weia, ' + env['sinatra.error'].message
|
2010-01-01 10:13:42 -05:00
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
Dann, wenn das passiert:
|
|
|
|
|
|
|
|
|
|
get '/' do
|
2011-03-18 11:11:34 -04:00
|
|
|
|
raise MeinFehler, 'etwas Schlimmes ist passiert'
|
2010-01-01 10:13:42 -05:00
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
bekommt man dieses:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Au weia, etwas Schlimmes ist passiert
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Alternativ kann ein Error-Handler auch für einen Status-Code definiert werden:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
error 403 do
|
|
|
|
|
'Zugriff verboten'
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
get '/geheim' do
|
|
|
|
|
403
|
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Oder ein Status-Code-Bereich:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
error 400..510 do
|
2011-03-18 11:11:34 -04:00
|
|
|
|
'Hallo?'
|
2010-01-01 10:13:42 -05:00
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Sinatra setzt verschiedene <tt>not_found</tt>- und <tt>error</tt>-Handler in
|
|
|
|
|
der Development-Umgebung.
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
== Rack-Middleware
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Sinatra baut auf Rack[http://rack.rubyforge.org/], einem minimalistischen
|
|
|
|
|
Standard-Interface für Ruby-Webframeworks. Eines der interessantesten
|
2011-03-18 11:11:34 -04:00
|
|
|
|
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.
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
2011-03-18 11:11:34 -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
|
2011-03-17 13:53:27 -04: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
|
2011-03-17 13:53:27 -04:00
|
|
|
|
+use+-Methode mehrere/verschiedene Argumente und auch Blöcke entgegennimmt:
|
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
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Rack bietet eine Vielzahl von Standard-Middlewares für Logging, Debugging,
|
2011-03-18 11:11:34 -04:00
|
|
|
|
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.
|
|
|
|
|
|
2011-05-19 14:30:11 -04:00
|
|
|
|
Hilfreiche Middleware gibt es z.B. hier:
|
|
|
|
|
{rack}[https://github.com/rack/rack/tree/master/lib/rack],
|
|
|
|
|
{rack-contrib}[https://github.com/rack/rack-contrib#readme],
|
|
|
|
|
mit {CodeRack}[http://coderack.org/] oder im
|
|
|
|
|
{Rack wiki}[https://github.com/rack/rack/wiki/List-of-Middleware].
|
|
|
|
|
|
2010-01-01 10:13:42 -05:00
|
|
|
|
== Testen
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Sinatra-Tests können mit jedem auf Rack aufbauendem Test-Framework geschrieben
|
2011-05-19 14:30:11 -04:00
|
|
|
|
werden. {Rack::Test}[http://rdoc.info/github/brynary/rack-test/master/frames]
|
|
|
|
|
wird empfohlen:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
require 'my_sinatra_app'
|
2010-10-13 12:59:58 -04:00
|
|
|
|
require 'test/unit'
|
2010-01-01 10:13:42 -05:00
|
|
|
|
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
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
== Sinatra::Base - Middleware, Bibliotheken und modulare Anwendungen
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
2011-03-18 11:11:34 -04:00
|
|
|
|
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.
|
2011-03-17 13:53:27 -04:00
|
|
|
|
|
|
|
|
|
Die Top-Level-DSL belastet den Objekt-Namespace und setzt einen
|
2011-05-19 14:30:11 -04:00
|
|
|
|
Mikro-Anwendungsstil voraus (eine einzelne Anwendungsdatei, <tt>./public</tt>
|
|
|
|
|
und <tt>./views</tt> Ordner, Logging, Exception-Detail-Seite, usw.). Genau
|
|
|
|
|
hier kommt <tt>Sinatra::Base</tt> 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
|
2011-03-18 11:11:34 -04:00
|
|
|
|
+use+ oder +run+ von einer Rackup-<tt>config.ru</tt>-Datei oder als
|
|
|
|
|
Server-Komponente einer Bibliothek:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
MyApp.run! :host => 'localhost', :port => 9090
|
|
|
|
|
|
2011-05-19 14:30:11 -04:00
|
|
|
|
Die Methoden der <tt>Sinatra::Base</tt>-Subklasse sind genau dieselben wie die
|
|
|
|
|
der Top-Level-DSL. Die meisten Top-Level-Anwendungen können mit nur zwei
|
|
|
|
|
Veränderungen zu <tt>Sinatra::Base</tt> 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
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Sinatras DSL-Methoden in den Top-Level-Namespace importiert.
|
|
|
|
|
* Alle Routen, Error-Handler, Filter und Optionen der Applikation müssen in
|
2011-05-19 14:30:11 -04:00
|
|
|
|
einer Subklasse von <tt>Sinatra::Base</tt> definiert werden.
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
<tt>Sinatra::Base</tt> ist ein unbeschriebenes Blatt. Die meisten Optionen sind
|
2011-03-17 13:53:27 -04:00
|
|
|
|
per Standard deaktiviert. Das betrifft auch den eingebauten Server. Siehe
|
2011-02-21 03:34:13 -05:00
|
|
|
|
{Optionen und Konfiguration}[http://sinatra.github.com/configuration.html] für
|
|
|
|
|
Details über mögliche Optionen.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
=== Modularer vs. klassischer Stil
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-02-21 03:36:31 -05:00
|
|
|
|
Entgegen häufiger Meinungen gibt es nichts gegen den klassischen Stil
|
2011-02-21 03:34:13 -05:00
|
|
|
|
einzuwenden. Solange es die Applikation nicht beeinträchtigt, besteht kein
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Grund, eine modulare Applikation zu erstellen.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
Lediglich zwei Nachteile gegenüber dem modularen Stil sollten beachtet werden:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
* Es kann nur eine Sinatra Applikation pro Ruby-Prozess laufen. Sollten mehrere
|
|
|
|
|
zum Einsatz kommen, muss auf den modularen Stil umgestiegen werden.
|
2011-02-21 03:34:13 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
* Der klassische Stil füllt Object mit Delegations-Methoden. Sollte die
|
|
|
|
|
Applikation als Gem/Bibliothek zum Einsatz kommen, sollte auf den modularen
|
|
|
|
|
Stil umgestiegen werden.
|
2011-02-21 03:34:13 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Es gibt keinen Grund, warum modulare und klassische Elemente nicht
|
|
|
|
|
vermischt werden sollten.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-02-21 03:36:31 -05:00
|
|
|
|
Will man jedoch von einem Stil auf den anderen umsteigen, sollten einige
|
2011-02-21 03:34:13 -05:00
|
|
|
|
Unterschiede beachtet werden:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
Szenario Classic Modular
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-05-19 14:30:11 -04:00
|
|
|
|
app_file sinatra ladende Datei Sinatra::Base subklassierende Datei
|
2011-02-19 20:37:22 -05:00
|
|
|
|
run $0 == app_file false
|
|
|
|
|
logging true false
|
|
|
|
|
method_override true false
|
|
|
|
|
inline_templates true false
|
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
=== Eine modulare Applikation bereitstellen
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Es gibt zwei übliche Wege, eine modulare Anwendung zu starten. Zum einen über
|
2011-02-19 20:37:22 -05:00
|
|
|
|
<tt>run!</tt>:
|
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
# mein_app.rb
|
2011-02-19 20:37:22 -05:00
|
|
|
|
require 'sinatra/base'
|
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
class MeinApp < Sinatra::Base
|
|
|
|
|
# ... Anwendungscode hierhin ...
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
# starte den Server, wenn die Ruby-Datei direkt ausgeführt wird
|
2011-02-19 20:37:22 -05:00
|
|
|
|
run! if app_file == $0
|
|
|
|
|
end
|
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
Starte mit:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
ruby mein_app.rb
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Oder über eine <tt>config.ru</tt>-Datei, die es erlaubt, einen beliebigen
|
|
|
|
|
Rack-Handler zu verwenden:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
# config.ru
|
2011-06-07 10:37:26 -04:00
|
|
|
|
require './mein_app'
|
2011-02-21 03:34:13 -05:00
|
|
|
|
run MeineApp
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
Starte:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
rackup -p 4567
|
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
=== Eine klassische Anwendung mit einer config.ru verwenden
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-02-21 03:34:13 -05:00
|
|
|
|
Schreibe eine Anwendungsdatei:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
# app.rb
|
|
|
|
|
require 'sinatra'
|
|
|
|
|
|
|
|
|
|
get '/' do
|
2011-02-21 03:34:13 -05:00
|
|
|
|
'Hallo Welt!'
|
2011-02-19 20:37:22 -05:00
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
sowie eine dazugehörige <tt>config.ru</tt>-Datei:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
require './app'
|
2011-02-19 20:37:22 -05:00
|
|
|
|
run Sinatra::Application
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
=== Wann sollte eine config.ru-Datei verwendet werden?
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Anzeichen dafür, dass eine <tt>config.ru</tt>-Datei gebraucht wird:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
* Es soll ein anderer Rack-Handler verwendet werden (Passenger, Unicorn,
|
2011-02-19 20:37:22 -05:00
|
|
|
|
Heroku, ...).
|
2011-03-17 13:53:27 -04:00
|
|
|
|
* Es gibt mehr als nur eine Subklasse von <tt>Sinatra::Base</tt>.
|
|
|
|
|
* Sinatra soll als Middleware verwendet werden, nicht als Endpunkt.
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
<b>Es gibt keinen Grund, eine <tt>config.ru</tt>-Datei zu verwenden, nur weil
|
2011-03-18 11:11:34 -04:00
|
|
|
|
eine Anwendung im modularen Stil betrieben werden soll. Ebenso wird keine
|
|
|
|
|
Anwendung mit modularem Stil benötigt, um eine <tt>config.ru</tt>-Datei zu
|
|
|
|
|
verwenden.</b>
|
|
|
|
|
|
2010-10-13 12:59:58 -04:00
|
|
|
|
=== Sinatra als Middleware nutzen
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Es ist nicht nur möglich, andere Rack-Middleware mit Sinatra zu nutzen, es kann
|
2011-03-18 11:11:34 -04:00
|
|
|
|
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
|
2011-03-06 18:21:13 -05:00
|
|
|
|
(Rails/Ramaze/Camping/...):
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
|
|
|
|
require 'sinatra/base'
|
|
|
|
|
|
|
|
|
|
class LoginScreen < Sinatra::Base
|
2010-11-07 03:49:23 -05:00
|
|
|
|
enable :sessions
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
|
|
|
|
get('/login') { haml :login }
|
|
|
|
|
|
|
|
|
|
post('/login') do
|
2011-05-19 14:30:11 -04:00
|
|
|
|
if params[:name] == 'admin' && params[:password] == 'admin'
|
2010-10-13 12:59:58 -04:00
|
|
|
|
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
|
|
|
|
|
|
2011-04-01 15:52:48 -04:00
|
|
|
|
=== Dynamische Applikationserstellung
|
|
|
|
|
|
|
|
|
|
Manche Situationen erfordern die Erstellung neuer Applikationen zur Laufzeit,
|
|
|
|
|
ohne dass sie einer Konstanten zugeordnet werden. Dies lässt sich mit
|
2011-04-30 08:20:11 -04:00
|
|
|
|
<tt>Sinatra.new</tt> erreichen:
|
2011-04-01 15:52:48 -04:00
|
|
|
|
|
|
|
|
|
require 'sinatra/base'
|
|
|
|
|
my_app = Sinatra.new { get('/') { "hallo" } }
|
|
|
|
|
my_app.run!
|
|
|
|
|
|
|
|
|
|
Die Applikation kann mit Hilfe eines optionalen Parameters erstellt werden:
|
|
|
|
|
|
2011-07-01 19:55:08 -04:00
|
|
|
|
# config.ru
|
2011-04-01 15:52:48 -04:00
|
|
|
|
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:
|
|
|
|
|
|
|
|
|
|
require 'sinatra/base'
|
|
|
|
|
|
|
|
|
|
use Sinatra do
|
|
|
|
|
get('/') { ... }
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
run RailsProject::Application
|
|
|
|
|
|
2011-02-19 20:37:22 -05:00
|
|
|
|
== Geltungsbereich und Bindung
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Der Geltungsbereich (Scope) legt fest, welche Methoden und Variablen zur
|
2011-02-19 20:37:22 -05:00
|
|
|
|
Verfügung stehen.
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
=== Anwendungs- oder Klassen-Scope
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
2011-05-19 14:30:11 -04:00
|
|
|
|
Jede Sinatra-Anwendung entspricht einer <tt>Sinatra::Base</tt>-Subklasse. Falls
|
|
|
|
|
die Top- Level-DSL verwendet wird (<tt>require 'sinatra'</tt>), handelt es sich
|
|
|
|
|
um <tt>Sinatra::Application</tt>, 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.
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Optionen, die via +set+ gesetzt werden, sind Methoden auf Klassenebene:
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
2010-11-10 14:15:51 -05:00
|
|
|
|
class MyApp < Sinatra::Base
|
2010-10-13 12:59:58 -04:00
|
|
|
|
# Hey, ich bin im Anwendungsscope!
|
|
|
|
|
set :foo, 42
|
|
|
|
|
foo # => 42
|
|
|
|
|
|
|
|
|
|
get '/foo' do
|
2011-03-17 13:53:27 -04:00
|
|
|
|
# Hey, ich bin nicht mehr im Anwendungs-Scope!
|
2010-10-13 12:59:58 -04:00
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Im Anwendungs-Scope befindet man sich:
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
* In der Anwendungs-Klasse.
|
|
|
|
|
* In Methoden, die von Erweiterungen definiert werden.
|
2011-02-21 03:40:23 -05:00
|
|
|
|
* Im Block, der an +helpers+ übergeben wird.
|
2011-03-17 13:53:27 -04:00
|
|
|
|
* In Procs und Blöcken, die an +set+ übergeben werden.
|
2011-04-01 15:52:48 -04:00
|
|
|
|
* Der an <tt>Sinatra.new</tt> übergebene Block
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Auf das Scope-Objekt (die Klasse) kann wie folgt zugegriffen werden:
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
* Über das Objekt, das an den +configure+-Block übergeben wird (<tt>configure
|
2010-10-13 12:59:58 -04:00
|
|
|
|
{ |c| ... }</tt>).
|
2011-02-21 03:40:23 -05:00
|
|
|
|
* +settings+ aus den anderen Scopes heraus.
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
=== Anfrage- oder Instanz-Scope
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
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:
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
2010-11-10 14:15:51 -05:00
|
|
|
|
class MyApp < Sinatra::Base
|
2011-03-17 13:53:27 -04:00
|
|
|
|
# Hey, ich bin im Anwendungs-Scope!
|
2010-10-13 12:59:58 -04:00
|
|
|
|
get '/neue_route/:name' do
|
2011-03-18 11:11:34 -04:00
|
|
|
|
# Anfrage-Scope für '/neue_route/:name'
|
2010-10-13 12:59:58 -04:00
|
|
|
|
@value = 42
|
|
|
|
|
|
|
|
|
|
settings.get "/#{params[:name]}" do
|
2011-03-17 13:53:27 -04:00
|
|
|
|
# Anfrage-Scope für "/#{params[:name]}"
|
|
|
|
|
@value # => nil (nicht dieselbe Anfrage)
|
2010-10-13 12:59:58 -04:00
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
"Route definiert!"
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Im Anfrage-Scope befindet man sich:
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
* In get/head/post/put/delete-Blöcken
|
|
|
|
|
* In before/after-Filtern
|
|
|
|
|
* In Helfer-Methoden
|
2010-10-13 12:59:58 -04:00
|
|
|
|
* In Templates
|
|
|
|
|
|
|
|
|
|
=== Delegation-Scope
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Vom Delegation-Scope aus werden Methoden einfach an den Klassen-Scope
|
|
|
|
|
weitergeleitet. Dieser verhält sich jedoch nicht 100%ig wie der Klassen-Scope,
|
2010-10-13 12:59:58 -04:00
|
|
|
|
da man nicht die Bindung der Klasse besitzt: Nur Methoden, die explizit als
|
2011-03-17 13:53:27 -04:00
|
|
|
|
delegierbar markiert wurden, stehen hier zur Verfügung und es kann nicht auf
|
|
|
|
|
die Variablen des Klassenscopes zugegriffen werden (mit anderen Worten: es gibt
|
2011-03-18 11:11:34 -04:00
|
|
|
|
ein anderes +self+). Weitere Delegationen können mit
|
|
|
|
|
<tt>Sinatra::Delegator.delegate :methoden_name</tt> hinzugefügt werden.
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
|
|
|
|
Im Delegation-Scop befindet man sich:
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
* Im Top-Level, wenn <tt>require 'sinatra'</tt> aufgerufen wurde.
|
|
|
|
|
* In einem Objekt, das mit dem <tt>Sinatra::Delegator</tt>-Mixin erweitert
|
2011-03-06 18:21:13 -05:00
|
|
|
|
wurde.
|
2010-10-13 12:59:58 -04:00
|
|
|
|
|
2011-02-21 03:36:31 -05:00
|
|
|
|
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
|
2011-02-21 03:34:13 -05:00
|
|
|
|
{globalen Namespace eingebunden}[http://github.com/sinatra/sinatra/blob/master/lib/sinatra/main.rb#L25].
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
== Kommandozeile
|
|
|
|
|
|
2011-03-17 13:53:27 -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)
|
2011-03-17 13:53:27 -04:00
|
|
|
|
-s # Rack-Server/Handler setzen (Standard ist thin)
|
|
|
|
|
-x # Mutex-Lock einschalten (Standard ist off)
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
2011-03-06 18:21:13 -05:00
|
|
|
|
== Systemanforderungen
|
|
|
|
|
|
|
|
|
|
Die folgenden Versionen werden offiziell unterstützt:
|
|
|
|
|
|
|
|
|
|
[ Ruby 1.8.7 ]
|
|
|
|
|
1.8.7 wird vollständig unterstützt, aber solange nichts dagegen spricht,
|
|
|
|
|
wird ein Update auf 1.9.2 oder ein Umstieg auf JRuby/Rubinius empfohlen.
|
|
|
|
|
|
|
|
|
|
[ Ruby 1.9.2 ]
|
|
|
|
|
1.9.2 wird unterstützt und empfohlen. Beachte, dass Markaby und Radius
|
2011-03-17 13:53:27 -04:00
|
|
|
|
momentan noch nicht kompatibel mit 1.9 sind. Version 1.9.0p0 sollte nicht
|
2011-03-06 18:21:13 -05:00
|
|
|
|
verwendet werden, da unter Sinatra immer wieder Segfaults auftreten.
|
|
|
|
|
|
|
|
|
|
[ Rubinius ]
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Rubinius (rbx >= 1.2.3) wird offiziell unter Einbezug aller Templates
|
|
|
|
|
unterstützt.
|
2011-03-06 18:21:13 -05:00
|
|
|
|
|
|
|
|
|
[ JRuby ]
|
2011-05-17 05:40:14 -04:00
|
|
|
|
JRuby wird offiziell unterstützt (JRuby >= 1.6.1). Probleme mit Template-
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Bibliotheken Dritter sind nicht bekannt. Falls JRuby zum Einsatz kommt,
|
|
|
|
|
sollte aber darauf geachtet werden, dass ein JRuby-Rack-Handler zum Einsatz
|
|
|
|
|
kommt – der Thin-Web-Server wird bisher nicht unterstütz. JRubys
|
|
|
|
|
Unterstützung für C-Erweiterungen sind zur Zeit noch experimenteller Natur,
|
2011-05-19 14:30:11 -04:00
|
|
|
|
betrifft im Moment aber nur RDiscount und Redcarpet.
|
2011-03-06 18:21:13 -05:00
|
|
|
|
|
2011-05-19 14:30:11 -04:00
|
|
|
|
<b>Ruby 1.8.6 wird nicht weiter unterstützt.</b> Falls Sinatra trotzdem unter
|
|
|
|
|
1.8.6 eingesetzt wird, muss Sinatra 1.2 verwendet werden, dass noch bis zum
|
|
|
|
|
Release von Sinatra 1.4.0 mit kleinen Bugfixes versorgt werden wird.
|
2011-04-01 15:52:48 -04:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Weiterhin werden wir auf kommende Ruby-Versionen ein Auge haben.
|
2011-03-06 18:21:13 -05:00
|
|
|
|
|
2011-06-07 10:37:26 -04:00
|
|
|
|
Die nachfolgend aufgeführten Ruby-Implementierungen werden offiziell nicht von
|
2011-03-06 18:21:13 -05:00
|
|
|
|
Sinatra unterstützt, funktionieren aber normalerweise:
|
|
|
|
|
|
|
|
|
|
* Ältere Versionen von JRuby und Rubinius
|
2011-03-18 11:11:34 -04:00
|
|
|
|
* MacRuby, Maglev, IronRuby
|
2011-03-06 18:21:13 -05:00
|
|
|
|
* Ruby 1.9.0 und 1.9.1
|
|
|
|
|
|
|
|
|
|
Nicht offiziell unterstützt bedeutet, dass wenn Sachen nicht funktionieren,
|
2011-03-17 13:53:27 -04:00
|
|
|
|
wir davon ausgehen, dass es nicht an Sinatra sondern an der jeweiligen
|
2011-03-06 18:21:13 -05:00
|
|
|
|
Implentierung liegt.
|
|
|
|
|
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Im Rahmen unserer CI (Kontinuierlichen Integration) wird bereits ruby-head
|
|
|
|
|
(das kommende Ruby 1.9.3) mit eingebunden. Da noch alles im Fluss ist, kann zur
|
|
|
|
|
Zeit für nichts garantiert werden. Es kann aber erwartet werden, dass Ruby
|
|
|
|
|
1.9.3p0 von Sinatra unterstützt werden wird.
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Sinatra sollte auf jedem Betriebssystem laufen, dass den gewählten Ruby-
|
2011-03-06 18:21:13 -05:00
|
|
|
|
Interpreter unterstützt.
|
|
|
|
|
|
2010-09-10 10:34:41 -04:00
|
|
|
|
== Der neueste Stand (The Bleeding Edge)
|
2011-04-18 07:19:43 -04:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Um auf dem neusten Stand zu bleiben, kann der Master-Branch verwendet werden.
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Er sollte recht stabil sein. Ebenso gibt es von Zeit zu Zeit prerelease Gems,
|
|
|
|
|
die so installiert werden:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
gem install sinatra --pre
|
|
|
|
|
|
|
|
|
|
=== Mit Bundler
|
2011-03-18 11:11:34 -04:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Wenn die Applikation mit der neuesten Version von Sinatra und
|
2011-04-14 02:51:59 -04:00
|
|
|
|
{Bundler}[http://gembundler.com/] genutzt werden soll, empfehlen wir den
|
|
|
|
|
nachfolgenden Weg.
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
2011-04-14 02:51:59 -04:00
|
|
|
|
Soweit Bundler noch nicht installiert ist:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
gem install bundler
|
2011-03-17 13:53:27 -04:00
|
|
|
|
|
|
|
|
|
Anschließend wird eine +Gemfile+-Datei im Projektverzeichnis mit folgendem
|
|
|
|
|
Inhalt erstellt:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
source :rubygems
|
|
|
|
|
gem 'sinatra', :git => "git://github.com/sinatra/sinatra.git"
|
|
|
|
|
|
|
|
|
|
# evtl. andere Abhängigkeiten
|
2011-03-17 13:53:27 -04:00
|
|
|
|
gem 'haml' # z.B. wenn du Haml verwendest...
|
2011-02-21 03:36:31 -05:00
|
|
|
|
gem 'activerecord', '~> 3.0' # ...oder ActiveRecord 3.x
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Beachte: Hier sollten alle Abhängigkeiten eingetragen werden. Sinatras eigene,
|
|
|
|
|
direkte Abhängigkeiten (Tilt und Rack) werden von Bundler automatisch aus dem
|
2011-02-19 20:37:22 -05:00
|
|
|
|
Gemfile von Sinatra hinzugefügt.
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Jetzt kannst du deine Applikation starten:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
bundle exec ruby myapp.rb
|
2011-03-18 11:11:34 -04:00
|
|
|
|
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
=== Eigenes Repository
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Um auf dem neuesten Stand von Sinatras Code zu sein, kann eine lokale Kopie
|
|
|
|
|
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
|
|
|
|
|
|
2011-03-17 13:53:27 -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
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Um Sinatra-Code von Zeit zu Zeit zu aktualisieren:
|
2010-01-01 10:13:42 -05:00
|
|
|
|
|
|
|
|
|
cd myproject/sinatra
|
|
|
|
|
git pull
|
|
|
|
|
|
2011-02-19 20:37:22 -05:00
|
|
|
|
=== Gem erstellen
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
Aus der eigenen lokalen Kopie kann nun auch ein globales Gem gebaut werden:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
git clone git://github.com/sinatra/sinatra.git
|
|
|
|
|
cd sinatra
|
|
|
|
|
rake sinatra.gemspec
|
|
|
|
|
rake install
|
|
|
|
|
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Falls Gems als Root installiert werden sollen, sollte die letzte Zeile
|
|
|
|
|
folgendermaßen lauten:
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
|
|
|
|
sudo rake install
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
== Versions-Verfahren
|
2011-02-19 20:37:22 -05:00
|
|
|
|
|
2011-03-18 11:11:34 -04:00
|
|
|
|
Sinatra folgt dem sogenannten {Semantic Versioning}[http://semver.org/], d.h.
|
|
|
|
|
SemVer und SemVerTag.
|
|
|
|
|
|
2010-01-01 10:13:42 -05:00
|
|
|
|
== Mehr
|
|
|
|
|
|
2011-03-17 13:53:27 -04:00
|
|
|
|
* {Projekt-Website}[http://sinatra.github.com/] - Ergänzende Dokumentation,
|
2010-01-01 10:13:42 -05:00
|
|
|
|
News und Links zu anderen Ressourcen.
|
2011-05-19 14:30:11 -04:00
|
|
|
|
* {Mitmachen}[http://sinatra.github.com/contributing.html] - Einen
|
2011-04-17 11:48:24 -04:00
|
|
|
|
Fehler gefunden? Brauchst du Hilfe? Hast du einen Patch?
|
2011-03-17 13:53:27 -04:00
|
|
|
|
* {Issue-Tracker}[http://github.com/sinatra/sinatra/issues]
|
2010-01-01 10:13:42 -05:00
|
|
|
|
* {Twitter}[http://twitter.com/sinatra]
|
2011-03-17 13:53:27 -04:00
|
|
|
|
* {Mailing-Liste}[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
|
2011-05-19 14:30:11 -04:00
|
|
|
|
* {Sinatra Book}[http://sinatra-book.gittr.com] Kochbuch Tutorial
|
|
|
|
|
* {Sinatra Book Contrib}[http://sinatra-book-contrib.com/] Sinatra-Rezepte aus
|
|
|
|
|
der Community
|
2011-04-18 07:19:43 -04:00
|
|
|
|
* API Dokumentation für die {aktuelle Version}[http://rubydoc.info/gems/sinatra]
|
|
|
|
|
oder für {HEAD}[http://rubydoc.info/github/sinatra/sinatra] auf
|
2011-04-17 11:48:24 -04:00
|
|
|
|
http://rubydoc.info
|