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