Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

regenerate readmes

  • Loading branch information...
commit 64378f9ac9d45debad8085061fde661f34e4aaba 1 parent 40f0abf
Konstantin Haase rkh authored
543 _includes/README.de.html
View
@@ -64,6 +64,7 @@
<li><a href='#Einstellung%20des%20Angriffsschutzes'>Einstellung des Angriffsschutzes</a></li>
<li><a href='#M%C3%B6gliche%20Einstellungen'>Mögliche Einstellungen</a></li>
</ol>
+ <li><a href='#Umgebungen'>Umgebungen</a></li>
<li><a href='#Fehlerbehandlung'>Fehlerbehandlung</a></li>
<ol class='level-2'>
<li><a href='#Nicht%20gefunden'>Nicht gefunden</a></li>
@@ -121,7 +122,7 @@
<p>Die Seite kann nun unter <a href="http://localhost:4567">localhost:4567</a>
betrachtet werden.</p>
-<p>Es wird empfohlen, den Thin-Server via <tt>gem install thin</tt> zu
+<p>Es wird empfohlen, den Thin-Server via <tt>gem install thin</tt> zu
installieren, den Sinatra dann, soweit vorhanden, automatisch verwendet.</p>
<a name='Routen'></a>
@@ -203,7 +204,7 @@
<p>Routen-Muster können auch mit optionalen Parametern ausgestattet werden:</p>
<pre>get '/posts.?:format?' do
- # passt auf &quot;GET /posts&quot; sowie jegliche Erweiterung
+ # passt auf &quot;GET /posts&quot; sowie jegliche Erweiterung
# wie &quot;GET /posts.json&quot;, &quot;GET /posts.xml&quot; etc.
end</pre>
@@ -215,8 +216,8 @@
<h3>Bedingungen</h3>
<p>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:</p>
+erfüllt sein müssen, damit der Block ausgeführt wird. Möglich wäre
+etwa eine Einschränkung des User-Agents:</p>
<pre>get '/foo', :agent =&gt; /Songbird (\d\.\d)[\d\/]*?/ do
&quot;Du verwendest Songbird Version #{params[:agent][0]}&quot;
@@ -254,12 +255,12 @@
end</pre>
<p>Bei Bedingungen, die mehrere Werte annehmen können, sollte ein Splat
-verwendet werden:</p>
+verwendet werden:</p>
<pre>set(:auth) do |*roles| # &lt;- hier kommt der Splat ins Spiel
condition do
unless logged_in? &amp;&amp; roles.any? {|role| current_user.in_role? role }
- redirect &quot;/login/&quot;, 303
+ redirect &quot;/login/&quot;, 303
end
end
end
@@ -278,20 +279,20 @@
<p>Durch den Rückgabewert eines Routen-Blocks wird mindestens der
Response-Body festgelegt, der an den HTTP-Client, bzw. die nächste
Rack-Middleware, weitergegeben wird. Im Normalfall handelt es sich hierbei,
-wie in den vorangehenden Beispielen zu sehen war, um einen String. Es
-werden allerdings auch andere Werte akzeptiert.</p>
+wie in den vorangehenden Beispielen zu sehen war, um einen String. Es
+werden allerdings auch andere Werte akzeptiert.</p>
-<p>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:</p>
+<p>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:</p>
<ul><li>
-<p>Ein Array mit drei Elementen: <tt>[Status (Fixnum), Headers (Hash),
+<p>Ein Array mit drei Elementen: <tt>[Status (Fixnum), Headers (Hash),
Response-Body (antwortet auf #each)]</tt>.</p>
</li><li>
<p>Ein Array mit zwei Elementen: <tt>[Status (Fixnum), Response-Body
(antwortet auf #each)]</tt>.</p>
</li><li>
-<p>Ein Objekt, das auf <tt>#each</tt> antwortet und den an diese Methode
+<p>Ein Objekt, das auf <tt>#each</tt> antwortet und den an diese Methode
übergebenen Block nur mit Strings als Übergabewerte aufruft.</p>
</li><li>
<p>Ein Fixnum, das den Status-Code festlegt.</p>
@@ -311,10 +312,10 @@
Streaming direkt in die Route integriert.</p>
<a name='Eigene%20Routen-Muster'></a>
-<h3>Eigene Routen-Muster </h3>
+<h3>Eigene Routen-Muster</h3>
-<p>Wie oben schon beschrieben, ist Sinatra von Haus aus mit Unterstützung für
-String-Muster und Reguläre Ausdrücke zum Abgleichen von Routen
+<p>Wie oben schon beschrieben, ist Sinatra von Haus aus mit Unterstützung
+für String-Muster und Reguläre Ausdrücke zum Abgleichen von Routen
ausgestattet. Das muss aber noch nicht alles sein, es können ohne großen
Aufwand eigene Routen-Muster erstellt werden:</p>
@@ -339,7 +340,7 @@
# ...
end</pre>
-<p>Beachte, dass das obige Beispiel etwas übertrieben wirkt. Es geht auch
+<p>Beachte, dass das obige Beispiel etwas übertrieben wirkt. Es geht auch
einfacher:</p>
<pre>get // do
@@ -372,13 +373,95 @@
<a name='Views/Templates'></a>
<h2>Views/Templates</h2>
-<p>Standardmäßig wird davon ausgegangen, dass sich Templates im
-<tt>./views</tt>-Ordner befinden. Es kann jedoch ein anderer Ordner
-festgelegt werden:</p>
+<p>Alle Templatesprachen verwenden ihre eigene Renderingmethode, die jeweils
+einen String zurückgibt:</p>
+
+<pre>get '/' do
+ erb :index
+end</pre>
+
+<p>Dieses Beispiel rendert <tt>views/index.erb</tt>.</p>
+
+<p>Anstelle eines Templatenamens kann man auch direkt die Templatesprache
+verwenden:</p>
+
+<pre>get '/' do
+ code = &quot;&lt;%= Time.now %&gt;&quot;
+ erb code
+end</pre>
+
+<p>Templates nehmen ein zweite Argument an, den Options-Hash:</p>
+
+<pre>get '/' do
+ erb :index, :layout =&gt; :post
+end</pre>
+
+<p>Dieses Beispiel rendert <tt>views/index.erb</tt> eingebettet in
+<tt>views/post.erb</tt> (Voreinstellung ist <tt>views/layout.erb</tt>,
+sofern es vorhanden ist.)</p>
+
+<p>Optionen, die Sinatra nicht versteht, werden an das Template
+weitergereicht:</p>
-<pre>set :views, File.dirname(__FILE__) + '/templates'</pre>
+<pre>get '/' do
+ haml :index, :format =&gt; :html5
+end</pre>
+
+<p>Für alle Templates können auch generelle Einstellungen festgelegt werden:</p>
+
+<pre>set :haml, :format =&gt; :html5
+
+get '/' do
+ haml :index
+end</pre>
+
+<p>Optionen, die an die Rendermethode weitergegeben werden, überschreiben die
+Einstellungen, die mit <tt>set</tt> festgelegt wurden.</p>
+
+<p>Mögliche Einstellungen:</p>
+<dl class="rdoc-list"><dt>locals</dt>
+<dd>
+<p>Liste von lokalen Variablen, die and das Dokument weitergegeben werden.
+Praktisch für Partials. Beispiel: <tt>erb &quot;&lt;%= foo %&gt;&quot;,
+:locals =&gt; {:foo =&gt; &quot;bar&quot;}</tt></p>
+</dd><dt>default_encoding</dt>
+<dd>
+<p>Gibt die Stringkodierung an, die verwendet werden soll. Voreingestellt auf
+<tt>settings.default_encoding</tt>.</p>
+</dd><dt>views</dt>
+<dd>
+<p>Ordner, aus dem die Templates heraus geladen werden. Voreingestellt auf
+<tt>settings.views</tt>.</p>
+</dd><dt>layout</dt>
+<dd>
+<p>Legt fest, ob ein Layouttemplate verwendet werden soll oder nicht
+(<tt>true</tt> oder <tt>false</tt>). Ist es ein Symbol, dass legt es fest,
+welches Template als Layout verwendet wird. Beispiel:</p>
-<p>Es ist zu beachten, dass immer mit Symbolen auf Templates verwiesen werden
+<pre>&lt;tt&gt;erb :index, :layout =&gt; !request.xhr?&lt;/tt&gt;</pre>
+</dd><dt>content_type</dt>
+<dd>
+<p>Content-Type den das Template ausgibt. Voreinstellung hängt von der
+Templatesprache ab.</p>
+</dd><dt>scope</dt>
+<dd>
+<p>Scope, in dem das Template gerendert wird. Liegt standardmäßig innerhalb
+der App-Instanz. Wird Scope geändert, sind Instanzvariablen und
+Helfermethoden nicht verfügbar.</p>
+</dd><dt>layout_engine</dt>
+<dd>
+<p>Legt fest, welcher Renderer für das Layout verantwortlich ist. Hilfreich
+für Sprachen, die sonst keine Templates unterstützen. Voreingestellt auf
+den Renderer, der für das Template verwendet wird. Beispiel: <tt>set
+:rdoc, :layout_engine =&gt; :erb</tt></p>
+</dd></dl>
+
+<p>Sinatra geht davon aus, dass die Templates sich im <tt>./views</tt>
+Verzeichnis befinden. Es kann jedoch ein anderer Ordner festgelegt werden:</p>
+
+<pre>set :views, settings.root + '/templates'</pre>
+
+<p>Es ist zu beachten, dass immer mit Symbolen auf Templates verwiesen werden
muss, auch dann, wenn sie sich in einem Unterordner befinden:</p>
<pre>haml :'unterverzeichnis/template'</pre>
@@ -390,7 +473,7 @@
<p>Einige Sprachen haben mehrere Implementierungen. Um festzulegen, welche
verwendet wird (und dann auch Thread-sicher ist), verwendet man am besten
-zu Beginn ein require:</p>
+zu Beginn ein 'require':</p>
<pre>require 'rdiscount' # oder require 'bluecloth'
get('/') { markdown :index }</pre>
@@ -509,9 +592,9 @@
<p><tt>liquid :index, :locals =&gt; { :key =&gt; 'Wert' }</tt></p>
</td></tr></table>
-<p>Da man aus dem Liquid-Template heraus keine Ruby-Methoden aufrufen kann
+<p>Da man aus dem Liquid-Template heraus keine Ruby-Methoden aufrufen kann
(ausgenommen <tt>yield</tt>), wird man üblicherweise locals verwenden
-wollen, mit denen man Variablen weitergibt.</p>
+wollen, mit denen man Variablen weitergibt.</p>
<a name='Markdown%20Templates'></a>
<h3>Markdown Templates</h3>
@@ -542,12 +625,12 @@
heraus aufrufen kann:</p>
<pre>%h1 Gruß von Haml!
-%p= markdown(:Grüsse)</pre>
+%p= markdown(:Grüße)</pre>
<p>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.</p>
+für die Templates zu verwenden und einen anderen für das Layout, indem
+die <tt>:layout_engine</tt>-Option verwendet wird.</p>
<a name='Textile%20Templates'></a>
<h3>Textile Templates</h3>
@@ -572,12 +655,12 @@
heraus aufrufen kann:</p>
<pre>%h1 Gruß von Haml!
-%p= textile(:Grüsse)</pre>
+%p= textile(:Grüße)</pre>
<p>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.</p>
+für die Templates zu verwenden und einen anderen für das Layout, indem
+die <tt>:layout_engine</tt>-Option verwendet wird.</p>
<a name='RDoc%20Templates'></a>
<h3>RDoc Templates</h3>
@@ -593,8 +676,8 @@
</td></tr></table>
<p>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:</p>
+keine locals verwenden kann, wird man RDoc üblicherweise in Kombination
+mit anderen Renderern verwenden wollen:</p>
<pre>erb :overview, :locals =&gt; { :text =&gt; rdoc(:einfuehrung) }</pre>
@@ -605,8 +688,8 @@
%p= rdoc(:Grüße)</pre>
<p>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
+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.</p>
<a name='Radius%20Templates'></a>
@@ -680,9 +763,9 @@
%p= creole(:Grüße)</pre>
<p>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.</p>
+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.</p>
<a name='CoffeeScript%20Templates'></a>
<h3>CoffeeScript Templates</h3>
@@ -713,7 +796,7 @@
<h3>Auf Variablen in Templates zugreifen</h3>
<p>Templates werden in demselben Kontext ausgeführt wie Routen.
-Instanzvariablen in Routen sind auch direkt im Template verfügbar:</p>
+Instanzvariablen in Routen sind auch direkt im Template verfügbar:</p>
<pre>get '/:id' do
@foo = Foo.find(params[:id])
@@ -753,13 +836,13 @@
<p>Anmerkung: Inline-Templates, die in der Datei definiert sind, die
<tt>require 'sinatra'</tt> aufruft, werden automatisch geladen. Um andere
Inline-Templates in anderen Dateien aufzurufen, muss explizit <tt>enable
-:inline_templates</tt> verwendet werden.</p>
+:inline_templates</tt> verwendet werden.</p>
<a name='Benannte%20Templates'></a>
<h3>Benannte Templates</h3>
-<p>Templates können auch mit der Top-Level <tt>template</tt>-Methode definiert
-werden:</p>
+<p>Templates können auch mit der Top-Level <tt>template</tt>-Methode
+definiert werden:</p>
<pre>template :layout do
&quot;%html\n =yield\n&quot;
@@ -773,9 +856,9 @@
haml :index
end</pre>
-<p>Wenn ein Template mit dem Namen layout existiert, wird es bei jedem
+<p>Wenn ein Template mit dem Namen "layout" existiert, wird es bei jedem
Aufruf verwendet. Durch <tt>:layout =&gt; false</tt> kann das Ausführen
-verhindert werden:</p>
+verhindert werden:</p>
<pre>get '/' do
haml :index, :layout =&gt; request.xhr?
@@ -784,17 +867,17 @@
<a name='Dateiendungen%20zuordnen'></a>
<h3>Dateiendungen zuordnen</h3>
-<p>Um eine Dateiendung einer Template-Engine zuzuordnen, kann
+<p>Um eine Dateiendung einer Template-Engine zuzuordnen, kann
<tt>Tilt.register</tt> genutzt werden. Wenn etwa die Dateiendung
-<tt>tt</tt> für Textile-Templates genutzt werden soll, lässt sich dies wie
-folgt bewerkstelligen:</p>
+<tt>tt</tt> für Textile-Templates genutzt werden soll, lässt sich dies
+wie folgt bewerkstelligen:</p>
<pre>Tilt.register :tt, Tilt[:textile]</pre>
<a name='Eine%20eigene%20Template-Engine%20hinzuf%C3%BCgen'></a>
<h3>Eine eigene Template-Engine hinzufügen</h3>
-<p>Zu allererst muss die Engine bei Tilt registriert und danach eine
+<p>Zu allererst muss die Engine bei Tilt registriert und danach eine
Rendering-Methode erstellt werden:</p>
<pre>Tilt.register :mtt, MeineTolleTemplateEngine
@@ -809,7 +892,7 @@
<p>Dieser Code rendert <tt>./views/application.mtt</tt>. Siehe <a
href="https://github.com/rtomayko/tilt">github.com/rtomayko/tilt</a>, um
-mehr über Tilt zu lernen.</p>
+mehr über Tilt zu lernen.</p>
<a name='Filter'></a>
<h2>Filter</h2>
@@ -895,10 +978,10 @@
<p>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 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:</p>
+verursachen viele Daten 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:</p>
<pre>use Rack::Session::Pool, :expire_after =&gt; 2592000
@@ -910,10 +993,10 @@
session[:value] = params[:value]
end</pre>
-<p>Um die Sicherheit zu erhöhen, werden Cookies, die Session-Daten führen, mit
-einem sogenannten Session-Secret signiert. Da sich dieses Geheimwort bei
-jedem Neustart der Applikation automatisch ändert, ist es sinnvoll, ein
-eigenes zu wählen, damit sich alle Instanzen der Applikation dasselbe
+<p>Um die Sicherheit zu erhöhen, werden Cookies, die Session-Daten führen,
+mit einem sogenannten Session-Secret signiert. Da sich dieses Geheimwort
+bei jedem Neustart der Applikation automatisch ändert, ist es sinnvoll,
+ein eigenes zu wählen, damit sich alle Instanzen der Applikation dasselbe
Session-Secret teilen:</p>
<pre>set :session_secret, 'super secret'</pre>
@@ -946,7 +1029,8 @@
<pre>halt 402, {'Content-Type' =&gt; 'text/plain'}, 'Rache'</pre>
-<p>Natürlich ist es auch möglich, ein Template mit <tt>halt</tt> zu verwenden:</p>
+<p>Natürlich ist es auch möglich, ein Template mit <tt>halt</tt> zu
+verwenden:</p>
<pre>halt erb(:error)</pre>
@@ -987,7 +1071,7 @@
<p>Beachte, dass in dem oben angegeben Beispiel die Performance erheblich
erhöht werden kann, wenn <tt>&quot;bar&quot;</tt> in eine Helfer-Methode
-umgewandelt wird, auf die <tt>/foo</tt> und <tt>/bar</tt> zugreifen
+umgewandelt wird, auf die <tt>/foo</tt> und <tt>/bar</tt> zugreifen
können.</p>
<p>Wenn der Request innerhalb derselben Applikations-Instanz aufgerufen und
@@ -1003,8 +1087,8 @@
einem Returnwert in der Route zu setzen. In manchen Situationen kann es
jedoch sein, dass der Body an irgendeiner anderen Stelle während der
Ausführung gesetzt wird. Das lässt sich mit der Helfer-Methode
-<tt>body</tt> bewerkstelligen. Wird <tt>body</tt> verwendet, lässt sich der
-Body jederzeit über diese Methode aufrufen:</p>
+<tt>body</tt> bewerkstelligen. Wird <tt>body</tt> verwendet, lässt sich
+der Body jederzeit über diese Methode aufrufen:</p>
<pre>get '/foo' do
body &quot;bar&quot;
@@ -1016,7 +1100,7 @@
<p>Ebenso ist es möglich, einen Block an <tt>body</tt> weiterzureichen, der
dann vom Rack-Handler ausgeführt wird (lässt sich z.B. zur Umsetzung von
-Streaming einsetzen, siehe auch Rückgabewerte).</p>
+Streaming einsetzen, siehe auch "Rückgabewerte").</p>
<p>Vergleichbar mit <tt>body</tt> lassen sich auch Status-Code und Header
setzen:</p>
@@ -1035,12 +1119,12 @@
<a name='Response-Streams'></a>
<h3>Response-Streams</h3>
-<p>In manchen Situationen sollen Daten bereits an den Client zurückgeschickt
+<p>In manchen Situationen sollen Daten bereits an den Client zurückgeschickt
werden, bevor ein vollständiger Response bereit steht. Manchmal will man
-die Verbindung auch erst dann beenden und Daten so lange an den Client
-zurückschicken, bis er die Verbindung abbricht. Für diese Fälle gibt es die
-<tt>stream</tt>-Helfer-Methode, die es einem erspart eigene Lösungen zu
-schreiben:</p>
+die Verbindung auch erst dann beenden und Daten so lange an den Client
+zurückschicken, bis er die Verbindung abbricht. Für diese Fälle gibt es
+die <tt>stream</tt>-Helfer-Methode, die es einem erspart eigene Lösungen
+zu schreiben:</p>
<pre>get '/' do
stream do |out|
@@ -1059,15 +1143,16 @@
wenn ein Teil der Daten von langsamen Ressourcen abhängig ist.</p>
<p>Es ist zu beachten, dass das Verhalten beim Streaming, insbesondere die
-Anzahl nebenläufiger Anfragen, stark davon abhängt, welcher Webserver für
-die Applikation verwendet wird. Einige Server, z.B. WEBRick, unterstützen
-Streaming nicht oder nur teilweise. Sollte der Server Streaming nicht
-unterstützen, wird ein vollständiger Response-Body zurückgeschickt, sobald
-der an <tt>stream</tt> weitergegebene Block abgearbeitet ist.</p>
+Anzahl nebenläufiger Anfragen, stark davon abhängt, welcher Webserver
+für die Applikation verwendet wird. Einige Server, z.B. WEBRick,
+unterstützen Streaming nicht oder nur teilweise. Sollte der Server
+Streaming nicht unterstützen, wird ein vollständiger Response-Body
+zurückgeschickt, sobald der an <tt>stream</tt> weitergegebene Block
+abgearbeitet ist. Mit Shotgun funktioniert Streaming z.B. überhaupt nicht.</p>
<p>Ist der optionale Parameter <tt>keep_open</tt> aktiviert, wird beim
gestreamten Objekt <tt>close</tt> nicht aufgerufen und es ist einem
-überlassen dies an einem beliebigen späteren Zeitpunkt nachholen. Die
+überlassen dies an einem beliebigen späteren Zeitpunkt nachholen. Die
Funktion ist jedoch nur bei Event-gesteuerten Serven wie Thin oder
Rainbows möglich, andere Server werden trotzdem den Stream beenden:</p>
@@ -1106,11 +1191,18 @@
<tt>Sinatra::Base</tt> vererbt, muss es erst aktiviert werden:</p>
<pre>class MyApp &lt; Sinatra::Base
- configure(:production, :development) do
+ configure :production, :development do
enable :logging
end
end</pre>
+<p>Damit auch keine Middleware das Logging aktivieren kann, muss die
+<tt>logging</tt> Einstellung auf <tt>nil</tt> gesetzt werden. Das heißt
+aber auch, dass <tt>logger</tt> in diesem Fall <tt>nil</tt> zurückgeben
+wird. Üblicherweise wird das eingesetzt, wenn ein eigener Logger
+eingerichtet werden soll. Sinatra wird dann verwenden, was in
+<tt>env['rack.logger']</tt> eingetragen ist.</p>
+
<a name='Mime-Types'></a>
<h2>Mime-Types</h2>
@@ -1133,7 +1225,7 @@
<h3>URLs generieren</h3>
<p>Zum Generieren von URLs sollte die <tt>url</tt>-Helfer-Methode genutzen
-werden, so z.B. beim Einsatz von Haml:</p>
+werden, so z.B. beim Einsatz von Haml:</p>
<pre>%a{:href =&gt; url('/foo')} foo</pre>
@@ -1157,7 +1249,7 @@
<pre>redirect to('/bar'), 303
redirect 'http://google.com', 'Hier bist du falsch'</pre>
-<p>Ebenso leicht lässt sich ein Schritt zurück mit dem Alias <tt>redirect
+<p>Ebenso leicht lässt sich ein Schritt zurück mit dem Alias <tt>redirect
back</tt> erreichen:</p>
<pre>get '/foo' do
@@ -1234,7 +1326,7 @@
<p>Diese Helfer führen nicht das eigentliche Caching aus, sondern geben die
dafür notwendigen Informationen an den Cache weiter. Für schnelle
-Reverse-Proxy Cache-Lösungen bietet sich z.B. <a
+Reverse-Proxy Cache-Lösungen bietet sich z.B. <a
href="http://rtomayko.github.com/rack-cache/">rack-cache</a> an:</p>
<pre>require &quot;rack/cache&quot;
@@ -1251,6 +1343,25 @@
<p>Um den <tt>Cache-Control</tt>-Header mit Informationen zu versorgen,
verwendet man die <tt>:static_cache_control</tt>-Einstellung (s.u.).</p>
+<p>Nach RFC 2616 sollte sich die Anwendung anders verhalten, wenn ein If-Match
+oder ein If-None_match Header auf <tt>*</tt> gesetzt wird in Abhängigkeit
+davon, ob die Resource bereits existiert. Sinatra geht davon aus, dass
+Ressourcen bei sicheren Anfragen (z.B. bei get oder Idempotenten Anfragen
+wie put) bereits existieren, wobei anderen Ressourcen (besipielsweise bei
+post), als neue Ressourcen behandelt werden. Dieses Verhalten lässt sich
+mit der <tt>:new_resource</tt> Option ändern:</p>
+
+<pre>get '/create' do
+ etag '', :new_resource =&gt; true
+ Article.create
+ erb :new_article
+end</pre>
+
+<p>Soll das schwache ETag trotzdem verwendet werden, verwendet man die
+<tt>:kind</tt> Option:</p>
+
+<pre>etag '', :new_resource =&gt; true, :kind =&gt; :weak</pre>
+
<a name='Dateien%20versenden'></a>
<h3>Dateien versenden</h3>
@@ -1284,10 +1395,10 @@
<p>Content-Length-Header. Standardwert ist die Dateigröße.</p>
</dd></dl>
-<p>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.</p>
+<p>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.</p>
<a name='Das%20Request-Objekt'></a>
<h2>Das Request-Objekt</h2>
@@ -1366,17 +1477,17 @@
<h3>Umgang mit Datum und Zeit</h3>
<p>Sinatra bietet eine <tt>time_for</tt>-Helfer-Methode, die aus einem
-gegebenen Wert ein Time-Objekt generiert. Ebenso kann sie nach
-<tt>DateTime</tt>, <tt>Date</tt> und ähnliche Klassen konvertieren:</p>
+gegebenen Wert ein Time-Objekt generiert. Ebenso kann sie nach
+<tt>DateTime</tt>, <tt>Date</tt> und ähnliche Klassen konvertieren:</p>
<pre>get '/' do
pass if Time.now &gt; time_for('Dec 23, 2012')
&quot;noch Zeit&quot;
end</pre>
-<p>Diese Methode wird intern für +expires, <tt>last_modiefied</tt> und Freunde
-verwendet. Mit ein paar Handgriffen lässt sich diese Methode also in ihrem
-Verhalten erweitern, indem man <tt>time_for</tt> in der eigenen
+<p>Diese Methode wird intern für +expires, <tt>last_modiefied</tt> und
+Freunde verwendet. Mit ein paar Handgriffen lässt sich diese Methode also
+in ihrem Verhalten erweitern, indem man <tt>time_for</tt> in der eigenen
Applikation überschreibt:</p>
<pre>helpers do
@@ -1405,9 +1516,9 @@
puts &quot;könnte diese hier sein: #{file}&quot;
end</pre>
-<p>Das ist zwar nicht wirklich brauchbar, aber wenn man sie überschreibt, kann
-sie nützlich werden, um eigene Nachschlage-Mechanismen einzubauen. Zum
-Beispiel dann, wenn mehr als nur ein view-Verzeichnis verwendet werden
+<p>Das ist zwar nicht wirklich brauchbar, aber wenn man sie überschreibt,
+kann sie nützlich werden, um eigene Nachschlage-Mechanismen einzubauen.
+Zum Beispiel dann, wenn mehr als nur ein view-Verzeichnis verwendet werden
soll:</p>
<pre>set :views, ['views', 'templates']
@@ -1434,13 +1545,14 @@
<p>Ebensogut könnte eine Extension aber auch geschrieben und mit anderen
geteilt werden!</p>
-<p>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
-möglichen Pfaden gesucht. Das ergibt kein Performance-Problem, da
-<tt>render</tt> <tt>block</tt> verwendet, sobald eine Datei gefunden wurde.
-Ebenso werden Template-Pfade samt Inhalt gecached, solange nicht im
-Entwicklungsmodus gearbeitet wird. Das sollte im Hinterkopf behalten
-werden, wenn irgendwelche verrückten Methoden zusammenbastelt werden.</p>
+<p>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 möglichen Pfaden gesucht. Das ergibt kein
+Performance-Problem, da <tt>render</tt> <tt>block</tt> verwendet, sobald
+eine Datei gefunden wurde. Ebenso werden Template-Pfade samt Inhalt
+gecached, solange nicht im Entwicklungsmodus gearbeitet wird. Das sollte im
+Hinterkopf behalten werden, wenn irgendwelche verrückten Methoden
+zusammenbastelt werden.</p>
<a name='Konfiguration'></a>
<h2>Konfiguration</h2>
@@ -1493,10 +1605,10 @@
<a name='Einstellung%20des%20Angriffsschutzes'></a>
<h3>Einstellung des Angriffsschutzes</h3>
-<p>Sinatra verwendet <a
+<p>Sinatra verwendet <a
href="https://github.com/rkh/rack-protection#readme">Rack::Protection</a>,
um die Anwendung vor häufig vorkommenden Angriffen zu schützen. Diese
-Voreinstellung lässt sich selbstverständlich auch deaktivieren, z.B. um
+Voreinstellung lässt sich selbstverständlich auch deaktivieren, z.B. um
Geschwindigkeitsvorteile zu gewinnen:</p>
<pre>disable :protection</pre>
@@ -1506,23 +1618,23 @@
<pre>set :protection, :except =&gt; :path_traversal</pre>
-<p>Neben Strings akzeptiert <tt>:except</tt> auch Arrays, um gleich mehrere
+<p>Neben Strings akzeptiert <tt>:except</tt> auch Arrays, um gleich mehrere
Schutzmechanismen zu deaktivieren:</p>
-<pre>set :protections, :except =&gt; [:path_traversal, :session_hijacking]</pre>
+<pre>set :protection, :except =&gt; [:path_traversal, :session_hijacking]</pre>
<a name='M%C3%B6gliche%20Einstellungen'></a>
<h3>Mögliche Einstellungen</h3>
<dl class="rdoc-list"><dt>absolute_redirects</dt>
<dd>
<p>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.</p>
+Sinatra dann nicht mehr mit RFC 2616 (HTTP 1.1) konform, das nur absolute
+Redirects zulässt.</p>
<p>Sollte eingeschaltet werden, wenn die Applikation hinter einem
-Reverse-Proxy liegt, der nicht ordentlich eingerichtet ist. Beachte, dass
-die <tt>url</tt>-Helfer-Methode nach wie vor absolute URLs erstellen
-wird, es sei denn, es wird als zweiter Parameter <tt>false</tt> angegeben.</p>
+Reverse-Proxy liegt, der nicht ordentlich eingerichtet ist. Beachte, dass
+die <tt>url</tt>-Helfer-Methode nach wie vor absolute URLs erstellen wird,
+es sei denn, es wird als zweiter Parameter <tt>false</tt> angegeben.</p>
<p>Standardmäßig nicht aktiviert.</p>
</dd><dt>add_charsets</dt>
@@ -1535,12 +1647,12 @@
<pre>settings.add_charsets &lt;&lt; &quot;application/foobar&quot;</pre>
</dd><dt>app_file</dt>
<dd>
-<p>Hauptdatei der Applikation. Wird verwendet, um das Wurzel-, Inline-, View-
-und öffentliche Verzeichnis des Projekts festzustellen.</p>
+<p>Pfad zur Hauptdatei der Applikation. Wird verwendet, um das Wurzel-,
+Inline-, View- und öffentliche Verzeichnis des Projekts festzustellen.</p>
</dd><dt>bind</dt>
<dd>
-<p>IP-Address, an die gebunden wird (Standardwert: 0.0.0.0). Wird nur für den
-eingebauten Server verwendet.</p>
+<p>IP-Address, an die gebunden wird (Standardwert: 0.0.0.0). Wird nur für den
+eingebauten Server verwendet.</p>
</dd><dt>default_encoding</dt>
<dd>
<p>Das Encoding, falls keines angegeben wurde. Standardwert ist
@@ -1572,28 +1684,33 @@
<p>Port für die Applikation. Wird nur im internen Server verwendet.</p>
</dd><dt>prefixed_redirects</dt>
<dd>
-<p>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.</p>
+<p>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.</p>
</dd><dt>protection</dt>
<dd>
-<p>Legt fest, ob der Schutzmechanismus für häufig Vorkommende Webangriffe auf
-Webapplikationen aktiviert wird oder nicht. Weitere Informationen im
-vorhergehenden Abschnitt.</p>
+<p>Legt fest, ob der Schutzmechanismus für häufig Vorkommende Webangriffe
+auf Webapplikationen aktiviert wird oder nicht. Weitere Informationen im
+vorhergehenden Abschnitt.</p>
</dd><dt>public_folder</dt>
<dd>
<p>Das öffentliche Verzeichnis, aus dem Daten zur Verfügung gestellt werden
-können.</p>
+können. Wird nur dann verwendet, wenn statische Daten zur Verfügung
+gestellt werden können (s.u. <tt>static</tt> Option). Leitet sich von der
+<tt>app_file</tt> Einstellung ab, wenn nicht gesetzt.</p>
</dd><dt>reload_templates</dt>
<dd>
<p>Im development-Modus aktiviert.</p>
</dd><dt>root</dt>
<dd>
-<p>Wurzelverzeichnis des Projekts.</p>
+<p>Wurzelverzeichnis des Projekts. Leitet sich von der <tt>app_file</tt>
+Einstellung ab, wenn nicht gesetzt.</p>
</dd><dt>raise_errors</dt>
<dd>
-<p>Einen Ausnahmezustand aufrufen. Beendet die Applikation.</p>
+<p>Einen Ausnahmezustand aufrufen. Beendet die Applikation. Ist automatisch
+aktiviert, wenn die Umgebung auf <tt>&quot;test&quot;</tt> eingestellt ist.
+Ansonsten ist diese Option deaktiviert.</p>
</dd><dt>run</dt>
<dd>
<p>Wenn aktiviert, wird Sinatra versuchen, den Webserver zu starten. Nicht
@@ -1603,34 +1720,59 @@
<p>Läuft der eingebaute Server? Diese Einstellung nicht ändern!</p>
</dd><dt>server</dt>
<dd>
-<p>Server oder Liste von Servern, die als eingebaute Server zur Verfügung
-stehen. Standardmäßig auf [thin’, ‘mongrel’, ‘webrick] voreingestellt.
+<p>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.</p>
</dd><dt>sessions</dt>
<dd>
-<p>Sessions auf Cookiebasis aktivieren.</p>
+<p>Sessions auf Cookiebasis mittels <tt>Rack::Session::Cookie</tt>aktivieren.
+Für weitere Infos bitte in der Sektion 'Sessions verwenden' nachschauen.</p>
</dd><dt>show_exceptions</dt>
<dd>
-<p>Stacktrace im Browser bei Fehlern anzeigen.</p>
+<p>Bei Fehlern einen Stacktrace im Browseranzeigen. Ist automatisch aktiviert,
+wenn die Umgebung auf <tt>&quot;development&quot;</tt> eingestellt ist.
+Ansonsten ist diese Option deaktiviert.</p>
</dd><dt>static</dt>
<dd>
<p>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
+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.</p>
</dd><dt>static_cache_control</dt>
<dd>
-<p>Wenn Sinatra statische Daten zur Verfügung stellt, können mit dieser
-Einstellung die <tt>Cache-Control</tt> Header zu den Responses hinzugefügt
-werden. Die Einstellung verwendet dazu die <tt>cache_control</tt>
+<p>Wenn Sinatra statische Daten zur Verfügung stellt, können mit dieser
+Einstellung die <tt>Cache-Control</tt> Header zu den Responses hinzugefügt
+werden. Die Einstellung verwendet dazu die <tt>cache_control</tt>
Helfer-Methode. Standardmäßig deaktiviert. Ein Array wird verwendet, um
mehrere Werte gleichzeitig zu übergeben: <tt>set :static_cache_control,
[:public, :max_age =&gt; 300]</tt></p>
</dd><dt>views</dt>
<dd>
-<p>Verzeichnis der Views.</p>
+<p>Verzeichnis der Views. Leitet sich von der <tt>app_file</tt> Einstellung
+ab, wenn nicht gesetzt.</p>
</dd></dl>
+<a name='Umgebungen'></a>
+<h2>Umgebungen</h2>
+
+<p>Es gibt drei voreingestellte Umgebungen in Sinatra:
+<tt>&quot;development&quot;</tt>, <tt>&quot;production&quot;</tt> und
+<tt>&quot;test&quot;</tt>. Umgebungen können über die <tt>RACK_ENV</tt>
+Umgebungsvariable gesetzt werden. Die Standardeinstellung ist
+<tt>&quot;development&quot;</tt>. In diesem Modus werden alle Templates
+zwischen Requests neu geladen. Dazu gibt es besondere Fehlerseiten für 404
+Stati und Fehlermeldungen. In <tt>&quot;production&quot;</tt> und
+<tt>&quot;test&quot;</tt> werden Templates automatisch gecached.</p>
+
+<p>Um die Anwendung in einer anderen Umgebung auszuführen kann man die
+<tt>-e</tt> Option verwenden:</p>
+
+<pre>ruby my_app.rb -e [ENVIRONMENT]</pre>
+
+<p>In der Anwendung kann man die die Methoden <tt>development?</tt>,
+<tt>test?</tt> und <tt>production?</tt> verwenden, um die aktuelle Umgebung
+zu erfahren.</p>
+
<a name='Fehlerbehandlung'></a>
<h2>Fehlerbehandlung</h2>
@@ -1701,10 +1843,10 @@
<p>Sinatra baut auf <a href="http://rack.rubyforge.org/">Rack</a>, einem
minimalistischen Standard-Interface für Ruby-Webframeworks. Eines der
interessantesten Features für Entwickler ist der Support von Middlewares,
-die zwischen den Server und die Anwendung geschaltet werden und so
+die zwischen den Server und die Anwendung geschaltet werden und so
HTTP-Request und/oder Antwort überwachen und/oder manipulieren können.</p>
-<p>Sinatra macht das Erstellen von Middleware-Verkettungen mit der
+<p>Sinatra macht das Erstellen von Middleware-Verkettungen mit der
Top-Level-Methode <tt>use</tt> zu einem Kinderspiel:</p>
<pre>require 'sinatra'
@@ -1728,9 +1870,9 @@
end</pre>
<p>Rack bietet eine Vielzahl von Standard-Middlewares für Logging, Debugging,
-URL-Routing, Authentifizierung und Session-Verarbeitung. Sinatra verwendet
+URL-Routing, Authentifizierung und Session-Verarbeitung. Sinatra verwendet
viele von diesen Komponenten automatisch, abhängig von der Konfiguration.
-So muss <tt>use</tt> häufig nicht explizit verwendet werden.</p>
+So muss <tt>use</tt> häufig nicht explizit verwendet werden.</p>
<p>Hilfreiche Middleware gibt es z.B. hier: <a
href="https://github.com/rack/rack/tree/master/lib/rack">rack</a>, <a
@@ -1776,16 +1918,15 @@
<a name='Sinatra::Base%20-%20Middleware,%20Bibliotheken%20und%20modulare%20Anwendungen'></a>
<h2>Sinatra::Base - Middleware, Bibliotheken und modulare Anwendungen</h2>
-<p>Das Definieren einer Top-Level-Anwendung funktioniert gut für
+<p>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
+wie Middleware, Rails Metal, einfache Bibliotheken mit Server-Komponenten
oder auch Sinatra-Erweiterungen geschrieben werden sollen.</p>
-<p>Die Top-Level-DSL belastet den Objekt-Namespace und setzt einen
-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:</p>
+<p>Das Top-Level geht von einer Konfiguration für eine Mikro-Anwendung aus
+(wie sie z.B. bei einer einzelnen Anwendungsdatei, <tt>./public</tt> und
+<tt>./views</tt> Ordner, Logging, Exception-Detail-Seite, usw.). Genau hier
+kommt <tt>Sinatra::Base</tt> ins Spiel:</p>
<pre>require 'sinatra/base'
@@ -1801,14 +1942,14 @@
<p>Die MyApp-Klasse ist eine unabhängige Rack-Komponente, die als Middleware,
Endpunkt oder via Rails Metal verwendet werden kann. Verwendet wird sie
durch <tt>use</tt> oder <tt>run</tt> von einer
-Rackup-<tt>config.ru</tt>-Datei oder als Server-Komponente einer
+Rackup-<tt>config.ru</tt>-Datei oder als Server-Komponente einer
Bibliothek:</p>
<pre>MyApp.run! :host =&gt; 'localhost', :port =&gt; 9090</pre>
<p>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:</p>
+zwei Veränderungen zu <tt>Sinatra::Base</tt> konvertiert werden:</p>
<ul><li>
<p>Die Datei sollte <tt>require 'sinatra/base'</tt> anstelle von <tt>require
'sinatra/base'</tt> aufrufen, ansonsten werden alle von Sinatras
@@ -1830,22 +1971,14 @@
einzuwenden. Solange es die Applikation nicht beeinträchtigt, besteht kein
Grund, eine modulare Applikation zu erstellen.</p>
-<p>Lediglich zwei Nachteile gegenüber dem modularen Stil sollten beachtet
-werden:</p>
-<ul><li>
-<p>Es kann nur eine Sinatra Applikation pro Ruby-Prozess laufen. Sollten
-mehrere zum Einsatz kommen, muss auf den modularen Stil umgestiegen werden.</p>
-</li><li>
-<p>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.</p>
-</li></ul>
-
-<p>Es gibt keinen Grund, warum modulare und klassische Elemente nicht
-vermischt werden sollten.</p>
+<p>Der größte Nachteil der klassischen Sinatra Anwendung gegenüber einer
+modularen ist die Einschränkung auf eine Sinatra Anwendung pro
+Ruby-Prozess. Sollen mehrere zum Einsatz kommen, muss auf den modularen
+Stil umgestiegen werden. Dabei ist es kein Problem klassische und modulare
+Anwendungen miteinander zu vermischen.</p>
-<p>Will man jedoch von einem Stil auf den anderen umsteigen, sollten einige
-Unterschiede beachtet werden:</p>
+<p>Bei einem Umstieg, sollten einige Unterschiede in den Einstellungen
+beachtet werden:</p>
<pre>Szenario Classic Modular
@@ -1909,7 +2042,7 @@
<p>Anzeichen dafür, dass eine <tt>config.ru</tt>-Datei gebraucht wird:</p>
<ul><li>
<p>Es soll ein anderer Rack-Handler verwendet werden (Passenger, Unicorn,
-Heroku, ).</p>
+Heroku, ...).</p>
</li><li>
<p>Es gibt mehr als nur eine Subklasse von <tt>Sinatra::Base</tt>.</p>
</li><li>
@@ -1918,17 +2051,17 @@
<p><b>Es gibt keinen Grund, eine <tt>config.ru</tt>-Datei zu verwenden, nur
weil 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></p>
+keine Anwendung mit modularem Stil benötigt, um eine
+<tt>config.ru</tt>-Datei zu verwenden.</b></p>
<a name='Sinatra%20als%20Middleware%20nutzen'></a>
<h3>Sinatra als Middleware nutzen</h3>
<p>Es ist nicht nur möglich, andere Rack-Middleware mit Sinatra zu nutzen, es
kann außerdem jede Sinatra-Anwendung selbst als Middleware vor jeden
-beliebigen Rack-Endpunkt gehangen werden. Bei diesem Endpunkt muss es sich
-nicht um eine andere Sinatra-Anwendung handeln, es kann jede andere
-Rack-Anwendung sein (Rails/Ramaze/Camping/):</p>
+beliebigen Rack-Endpunkt gehangen werden. Bei diesem Endpunkt muss es sich
+nicht um eine andere Sinatra-Anwendung handeln, es kann jede andere
+Rack-Anwendung sein (Rails/Ramaze/Camping/...):</p>
<pre>require 'sinatra/base'
@@ -1963,8 +2096,8 @@
<h3>Dynamische Applikationserstellung</h3>
<p>Manche Situationen erfordern die Erstellung neuer Applikationen zur
-Laufzeit, ohne dass sie einer Konstanten zugeordnet werden. Dies lässt sich
-mit <tt>Sinatra.new</tt> erreichen:</p>
+Laufzeit, ohne dass sie einer Konstanten zugeordnet werden. Dies lässt
+sich mit <tt>Sinatra.new</tt> erreichen:</p>
<pre>require 'sinatra/base'
my_app = Sinatra.new { get('/') { &quot;hallo&quot; } }
@@ -2013,10 +2146,10 @@
<p>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 <tt>get</tt> oder <tt>before</tt> zur Verfügung, es gibt aber keinen
-Zugriff auf das <tt>request</tt>-Object oder die <tt>session</tt>, da nur
-eine einzige Klasse für alle eingehenden Anfragen genutzt wird.</p>
+Subklasse, die explizit angelegt wurde. Auf Klassenebene stehen Methoden
+wie <tt>get</tt> oder <tt>before</tt> zur Verfügung, es gibt aber keinen
+Zugriff auf das <tt>request</tt>-Object oder die <tt>session</tt>, da nur
+eine einzige Klasse für alle eingehenden Anfragen genutzt wird.</p>
<p>Optionen, die via <tt>set</tt> gesetzt werden, sind Methoden auf
Klassenebene:</p>
@@ -2094,17 +2227,17 @@
<p>Vom Delegation-Scope aus werden Methoden einfach an den Klassen-Scope
weitergeleitet. Dieser verhält sich jedoch nicht 100%ig wie der
Klassen-Scope, da man nicht die Bindung der Klasse besitzt: Nur Methoden,
-die explizit als delegierbar markiert wurden, stehen hier zur Verfügung und
-es kann nicht auf die Variablen des Klassenscopes zugegriffen werden (mit
-anderen Worten: es gibt ein anderes <tt>self</tt>). Weitere Delegationen
-können mit <tt>Sinatra::Delegator.delegate :methoden_name</tt> hinzugefügt
-werden.</p>
+die explizit als delegierbar markiert wurden, stehen hier zur Verfügung
+und es kann nicht auf die Variablen des Klassenscopes zugegriffen werden
+(mit anderen Worten: es gibt ein anderes <tt>self</tt>). Weitere
+Delegationen können mit <tt>Sinatra::Delegator.delegate
+:methoden_name</tt> hinzugefügt werden.</p>
<p>Im Delegation-Scop befindet man sich:</p>
<ul><li>
<p>Im Top-Level, wenn <tt>require 'sinatra'</tt> aufgerufen wurde.</p>
</li><li>
-<p>In einem Objekt, das mit dem <tt>Sinatra::Delegator</tt>-Mixin erweitert
+<p>In einem Objekt, das mit dem <tt>Sinatra::Delegator</tt>-Mixin erweitert
wurde.</p>
</li></ul>
@@ -2137,45 +2270,49 @@
<p>Die folgenden Versionen werden offiziell unterstützt:</p>
<dl class="rdoc-list"><dt> Ruby 1.8.7 </dt>
<dd>
-<p>1.8.7 wird vollständig unterstützt, aber solange nichts dagegen spricht,
+<p>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.
Unterstützung für 1.8.7 wird es mindestens bis Sinatra 2.0 und Ruby 2.0
geben, es sei denn, dass der unwahrscheinliche Fall eintritt und 1.8.8
rauskommt. Doch selbst dann ist es eher wahrscheinlich, dass 1.8.7
-weiterhin unterstützt wird. <b>Ruby 1.8.6 wird nicht mehr unterstützt.</b>
-Soll Sinatra unter 1.8.6 eingesetzt werden, muss Sinatra 1.2 verwendet
-werden, dass noch bis zum Release von Sinatra 1.4.0 fortgeführt wird.</p>
+weiterhin unterstützt wird. <b>Ruby 1.8.6 wird nicht mehr
+unterstützt.</b> Soll Sinatra unter 1.8.6 eingesetzt werden, muss Sinatra
+1.2 verwendet werden, dass noch bis zum Release von Sinatra 1.4.0
+fortgeführt wird.</p>
</dd><dt> Ruby 1.9.2 </dt>
<dd>
-<p>1.9.2 wird voll unterstützt und empfohlen. Beachte, dass Markaby und Radius
-momentan noch nicht kompatibel mit 1.9 sind. Version 1.9.2p0 sollte nicht
-verwendet werden, da unter Sinatra immer wieder Segfaults auftreten.
+<p>1.9.2 wird voll unterstützt und empfohlen. Beachte, dass Markaby und
+Radius momentan noch nicht kompatibel mit 1.9 sind. Version 1.9.2p0 sollte
+nicht verwendet werden, da unter Sinatra immer wieder Segfaults auftreten.
Unterstützung wird es mindestens bis zum Release von Ruby 1.9.4/2.0 geben
und das letzte Sinatra Release für 1.9 wird so lange unterstützt, wie das
-Ruby Core-Team 1.9 pflegt.</p>
+Ruby Core-Team 1.9 pflegt.</p>
</dd><dt> Ruby 1.9.3 </dt>
<dd>
-<p>Obwohl Tests bereits auf 1.9.3 laufen, sind bisher keine Applikationen auf
-1.9.3 in Produktion bekannt. Ebenso wie bei 1.9.2 besteht die gleiche
-Warnung zum Patchlevel 0.</p>
+<p>1.9.3 wird vollständig unterstützt. Momentan wird empfohlen auf einen
+höheren Pachtlevel zu warten, bevor Sinatra in der Produktion eingesetzt
+wird (aktueller Patchlevel ist p0). Bei einem Wechsel zu 1.9.3 werden alle
+Sessions ungültig. Obwohl Tests bereits auf 1.9.3 laufen, sind bisher
+keine Applikationen auf 1.9.3 in Produktion bekannt. Ebenso wie bei 1.9.2
+besteht die gleiche Warnung zum Patchlevel 0.</p>
</dd><dt> Rubinius </dt>
<dd>
-<p>Rubinius (rbx &gt;= 1.2.4) wird offiziell unter Einbezug aller Templates
-unterstützt.</p>
+<p>Rubinius (rbx &gt;= 1.2.4) wird offiziell unter Einbezug aller Templates
+unterstützt. Die kommende 2.0 Version wird ebenfalls unterstützt.</p>
</dd><dt> JRuby </dt>
<dd>
-<p>JRuby wird offiziell unterstützt (JRuby &gt;= 1.6.3). Probleme mit
+<p>JRuby wird offiziell unterstützt (JRuby &gt;= 1.6.5). Probleme mit
Template- 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,
-betrifft im Moment aber nur RDiscount und Redcarpet.</p>
+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, betrifft im Moment aber nur RDiscount, Redcarpet und RedCloth.</p>
</dd></dl>
<p>Weiterhin werden wir auf kommende Ruby-Versionen ein Auge haben.</p>
<p>Die nachfolgend aufgeführten Ruby-Implementierungen werden offiziell nicht
-von Sinatra unterstützt, funktionieren aber normalerweise:</p>
+von Sinatra unterstützt, funktionieren aber normalerweise:</p>
<ul><li>
<p>Ruby Enterprise Edition</p>
</li><li>
@@ -2186,14 +2323,14 @@
<p>Ruby 1.9.0 und 1.9.1 (wird jedoch nicht empfohlen, s.o.)</p>
</li></ul>
-<p>Nicht offiziell unterstützt bedeutet, dass wenn Sachen nicht funktionieren,
-wir davon ausgehen, dass es nicht an Sinatra sondern an der jeweiligen
-Implentierung liegt.</p>
+<p>Nicht offiziell unterstützt bedeutet, dass wenn Sachen nicht
+funktionieren, wir davon ausgehen, dass es nicht an Sinatra sondern an der
+jeweiligen Implentierung liegt.</p>
<p>Im Rahmen unserer CI (Kontinuierlichen Integration) wird bereits ruby-head
-(das kommende Ruby 1.9.4) 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.4p0 von Sinatra unterstützt werden wird.</p>
+(das kommende Ruby 2.0.0) und 1.9.4 mit eingebunden. Da noch alles im Fluss
+ist, kann zur Zeit für nichts garantiert werden. Es kann aber erwartet
+werden, dass Ruby 2.0.0p0 und 1.9.4p0 von Sinatra unterstützt werden wird.</p>
<p>Sinatra sollte auf jedem Betriebssystem laufen, dass den gewählten Ruby-
Interpreter unterstützt.</p>
@@ -2206,7 +2343,7 @@
<p>Um auf dem neusten Stand zu bleiben, kann der Master-Branch verwendet
werden. Er sollte recht stabil sein. Ebenso gibt es von Zeit zu Zeit
-prerelease Gems, die so installiert werden:</p>
+prerelease Gems, die so installiert werden:</p>
<pre>gem install sinatra --pre</pre>
@@ -2276,7 +2413,7 @@
rake sinatra.gemspec
rake install</pre>
-<p>Falls Gems als Root installiert werden sollen, sollte die letzte Zeile
+<p>Falls Gems als Root installiert werden sollen, sollte die letzte Zeile
folgendermaßen lauten:</p>
<pre>sudo rake install</pre>
@@ -2285,7 +2422,7 @@
<h2>Versions-Verfahren</h2>
<p>Sinatra folgt dem sogenannten <a href="http://semver.org/">Semantic
-Versioning</a>, d.h. SemVer und SemVerTag.</p>
+Versioning</a>, d.h. SemVer und SemVerTag.</p>
<a name='Mehr'></a>
<h2>Mehr</h2>
435 _includes/README.es.html
View
@@ -58,6 +58,7 @@
<li><a href='#Configurando%20la%20Protecci%C3%B3n%20de%20Ataques'>Configurando la Protección de Ataques</a></li>
<li><a href='#Configuraciones%20Disponibles'>Configuraciones Disponibles</a></li>
</ol>
+ <li><a href='#Entornos'>Entornos</a></li>
<li><a href='#Manejo%20de%20Errores'>Manejo de Errores</a></li>
<ol class='level-2'>
<li><a href='#No%20encontrado%20%3Cem%3E(Not%20Found)%3C/em%3E'>No encontrado <em>(Not Found)</em></a></li>
@@ -95,8 +96,8 @@
-<p><em>Atención: Este documento es una traducción de la versión en inglés y
-puede estar desactualizado.</em></p>
+<p><em>Atención: Este documento es una traducción de la versión en inglés
+y puede estar desactualizado.</em></p>
<p>Sinatra es un DSL para crear aplicaciones web rápidamente en Ruby con un
mínimo esfuerzo:</p>
@@ -121,8 +122,8 @@
<a name='Rutas'></a>
<h2>Rutas</h2>
-<p>En Sinatra, una ruta está compuesta por un método HTTP y un patrón de una
-URL. Cada ruta se asocia con un bloque:</p>
+<p>En Sinatra, una ruta está compuesta por un método HTTP y un patrón de
+una URL. Cada ruta se asocia con un bloque:</p>
<pre>get '/' do
.. mostrar algo ..
@@ -151,8 +152,8 @@
<p>Las rutas son comparadas en el orden en el que son definidas. La primer
ruta que coincide con la petición es invocada.</p>
-<p>Los patrones de las rutas pueden incluir parámetros nombrados, accesibles a
-través de el hash <tt>params</tt>:</p>
+<p>Los patrones de las rutas pueden incluir parámetros nombrados, accesibles
+a través de el hash <tt>params</tt>:</p>
<pre>get '/hola/:nombre' do
# coincide con &quot;GET /hola/foo&quot; y &quot;GET /hola/bar&quot;
@@ -167,8 +168,8 @@
&quot;Hola #{n}!&quot;
end</pre>
-<p>Los patrones de ruta también pueden incluir parámetros splat (o wildcard),
-accesibles a través del arreglo <tt>params[:splat]</tt>:</p>
+<p>Los patrones de ruta también pueden incluir parámetros splat (o
+wildcard), accesibles a través del arreglo <tt>params[:splat]</tt>:</p>
<pre>get '/decir/*/al/*' do
# coincide con /decir/hola/al/mundo
@@ -205,15 +206,15 @@
# ejemplo, &quot;GET /posts.json&quot;, &quot;GET /posts.xml&quot;, etc.
end</pre>
-<p>A propósito, a menos que desactivés la protección para el ataque <em>path
-traversal</em> (ver más abajo), el path de la petición puede ser modificado
-antes de que se compare con los de tus rutas.</p>
+<p>A propósito, a menos que desactivés la protección para el ataque
+<em>path traversal</em> (ver más abajo), el path de la petición puede ser
+modificado antes de que se compare con los de tus rutas.</p>
<a name='Condiciones'></a>
<h3>Condiciones</h3>
-<p>Las rutas pueden incluir una variedad de condiciones de selección, como por
-ejemplo el user agent:</p>
+<p>Las rutas pueden incluir una variedad de condiciones de selección, como
+por ejemplo el user agent:</p>
<pre>get '/foo', :agent =&gt; /Songbird (\d\.\d)[\d\/]*?/ do
&quot;Estás usando la versión de Songbird #{params[:agent][0]}&quot;
@@ -249,8 +250,8 @@
&quot;Lo siento, perdiste.&quot;
end</pre>
-<p>Si tu condición acepta más de un argumento, podés pasarle un arreglo. Al
-definir la condición puede resultarte conveniente utilizar el operador
+<p>Si tu condición acepta más de un argumento, podés pasarle un arreglo.
+Al definir la condición puede resultarte conveniente utilizar el operador
splat en la lista de parámetros:</p>
<pre>set(:autorizar) do |*roles| # &lt;- mirá el splat
@@ -278,8 +279,8 @@
anteriores. Sin embargo, otros valor también son aceptados.</p>
<p>Podés devolver cualquier objeto que sea una respuesta Rack válida, un
-objeto que represente el cuerpo de una respuesta Rack o un código de estado
-HTTP:</p>
+objeto que represente el cuerpo de una respuesta Rack o un código de
+estado HTTP:</p>
<ul><li>
<p>Un arreglo con tres elementos: <tt>[estado (Fixnum), cabeceras (Hash),
cuerpo de la respuesta (responde a #each)]</tt></p>
@@ -287,8 +288,8 @@
<p>Un arreglo con dos elementos: <tt>[estado (Fixnum), cuerpo de la respuesta
(responde a #each)]</tt></p>
</li><li>
-<p>Un objeto que responde a <tt>#each</tt> y que le pasa únicamente strings al
-bloque dado</p>
+<p>Un objeto que responde a <tt>#each</tt> y que le pasa únicamente strings
+al bloque dado</p>
</li><li>
<p>Un Fixnum representando el código de estado</p>
</li></ul>
@@ -354,13 +355,13 @@
<pre>set :public_folder, File.dirname(__FILE__) + '/estaticos'</pre>
-<p>Notá que el nombre del directorio público no está incluido en la URL. Por
-ejemplo, el archivo <tt>./public/css/style.css</tt> se accede a través de
-<tt>http://ejemplo.com/css/style.css</tt>.</p>
+<p>Notá que el nombre del directorio público no está incluido en la URL.
+Por ejemplo, el archivo <tt>./public/css/style.css</tt> se accede a través
+de <tt>http://ejemplo.com/css/style.css</tt>.</p>
<p>Usá la configuración <tt>:static_cache_control</tt> para agregar el
-encabezado <tt>Cache-Control</tt> (ver la sección de configuración para más
-detalles).</p>
+encabezado <tt>Cache-Control</tt> (ver la sección de configuración para
+más detalles).</p>
<a name='Vistas%20/%20Plantillas'></a>
<h2>Vistas / Plantillas</h2>
@@ -382,8 +383,8 @@
erb codigo
end</pre>
-<p>Los métodos de renderizado, aceptan además un segundo argumento, el hash de
-opciones:</p>
+<p>Los métodos de renderizado, aceptan además un segundo argumento, el hash
+de opciones:</p>
<pre>get '/' do
erb :index, :layout =&gt; :post
@@ -429,8 +430,9 @@
</dd><dt>layout</dt>
<dd>
<p>Si es <tt>true</tt> o <tt>false</tt> indica que se debe usar, o nó, un
-layout, respectivamente. También puede ser un símbolo que especifique qué
-plantilla usar. Ejemplo: <tt>erb :index, :layout =&gt; !request.xhr?</tt></p>
+layout, respectivamente. También puede ser un símbolo que especifique
+qué plantilla usar. Ejemplo: <tt>erb :index, :layout =&gt;
+!request.xhr?</tt></p>
</dd><dt>content_type</dt>
<dd>
<p>Content-Type que produce la plantilla. El valor por defecto depende de
@@ -438,8 +440,8 @@
</dd><dt>scope</dt>
<dd>
<p>Ámbito en el que se renderiza la plantilla. Por defecto utiliza la
-instancia de la aplicación. Tené en cuenta que si cambiás esta opción las
-variables de instancia y los helpers van a dejar de estar disponibles.</p>
+instancia de la aplicación. Tené en cuenta que si cambiás esta opción
+las variables de instancia y los helpers van a dejar de estar disponibles.</p>
</dd><dt>layout_engine</dt>
<dd>
<p>Motor de renderizado de plantillas que usa para el layout. Resulta
@@ -456,15 +458,15 @@
<p>Es importante acordarse que siempre tenés que referenciar a las plantillas
con símbolos, incluso cuando se encuentran en un subdirectorio (en este
caso tenés que usar <tt>:'subdir/plantilla'</tt>). Tenés que usar un
-símbolo porque los métodos de renderización van a renderizar directamente
-cualquier string que se les pase como argumento.</p>
+símbolo porque los métodos de renderización van a renderizar
+directamente cualquier string que se les pase como argumento.</p>
<a name='Lenguajes%20de%20Plantillas%20Disponibles'></a>
<h3>Lenguajes de Plantillas Disponibles</h3>
<p>Algunos lenguajes tienen varias implementaciones. Para especificar que
-implementación usar (y para ser thread-safe), deberías requerirla antes de
-usarla:</p>
+implementación usar (y para ser thread-safe), deberías requerirla antes
+de usarla:</p>
<pre>require 'rdiscount' # o require 'bluecloth'
get('/') { markdown :index }</pre>
@@ -606,15 +608,15 @@
<pre>erb :resumen, :locals =&gt; { :texto =&gt; markdown(:introduccion) }</pre>
-<p>Tené en cuenta que también podés llamar al método <tt>markdown</tt> desde
-otras plantillas:</p>
+<p>Tené en cuenta que también podés llamar al método <tt>markdown</tt>
+desde otras plantillas:</p>
<pre>%h1 Hola Desde Haml!
%p= markdown(:saludos)</pre>
-<p>Como no podés utilizar Ruby desde Markdown, no podés usar layouts escritos
-en Markdown. De todos modos, es posible usar un motor de renderizado para
-el layout distinto al de la plantilla pasando la opción
+<p>Como no podés utilizar Ruby desde Markdown, no podés usar layouts
+escritos en Markdown. De todos modos, es posible usar un motor de
+renderizado para el layout distinto al de la plantilla pasando la opción
<tt>:layout_engine</tt>.</p>
<a name='Plantillas%20Textile'></a>
@@ -636,8 +638,8 @@
<pre>erb :resumen, :locals =&gt; { :texto =&gt; textile(:introduccion) }</pre>
-<p>Tené en cuenta que también podés llamar al método <tt>textile</tt> desde
-otras plantillas:</p>
+<p>Tené en cuenta que también podés llamar al método <tt>textile</tt>
+desde otras plantillas:</p>
<pre>%h1 Hola Desde Haml!
%p= textile(:saludos)</pre>
@@ -665,8 +667,8 @@
<pre>erb :resumen, :locals =&gt; { :texto =&gt; rdoc(:introduccion) }</pre>
-<p>Tené en cuenta que también podés llamar al método <tt>rdoc</tt> desde otras
-plantillas:</p>
+<p>Tené en cuenta que también podés llamar al método <tt>rdoc</tt> desde
+otras plantillas:</p>
<pre>%h1 Hola Desde Haml!
%p= rdoc(:saludos)</pre>
@@ -746,8 +748,8 @@
<pre>%h1 Hola Desde Haml!
%p= creole(:saludos)</pre>
-<p>Como no podés utilizar Ruby desde Creole, no podés usar layouts escritos en
-Creloe. De todos modos, es posible usar un motor de renderizado para el
+<p>Como no podés utilizar Ruby desde Creole, no podés usar layouts escritos
+en Creloe. De todos modos, es posible usar un motor de renderizado para el
layout distinto al de la plantilla pasando la opción
<tt>:layout_engine</tt>.</p>
@@ -842,7 +844,7 @@
haml :index
end</pre>
-<p>Si existe una plantilla con el nombre layout, va a ser usada cada vez que
+<p>Si existe una plantilla con el nombre "layout", va a ser usada cada vez que
una plantilla es renderizada. Podés desactivar los layouts individualmente
pasando <tt>:layout =&gt; false</tt> o globalmente con <tt>set :haml,
:layout =&gt; false</tt>:</p>
@@ -883,10 +885,10 @@
<a name='Filtros'></a>
<h2>Filtros</h2>
-<p>Los filtros <tt>before</tt> son evaluados antes de cada petición dentro del
-mismo contexto que las rutas. Pueden modificar la petición y la respuesta.
-Las variables de instancia asignadas en los filtros son accesibles por las
-rutas y las plantillas:</p>
+<p>Los filtros <tt>before</tt> son evaluados antes de cada petición dentro
+del mismo contexto que las rutas. Pueden modificar la petición y la
+respuesta. Las variables de instancia asignadas en los filtros son
+accesibles por las rutas y las plantillas:</p>
<pre>before do
@nota = 'Hey!'
@@ -899,7 +901,7 @@
end</pre>
<p>Los filtros <tt>after</tt> son evaluados después de cada petición dentro
-del mismo contexto y también pueden modificar la petición y la respuesta.
+del mismo contexto y también pueden modificar la petición y la respuesta.
Las variables de instancia asignadas en los filtros <tt>before</tt> y en
las rutas son accesibles por los filtros <tt>after</tt>:</p>
@@ -911,9 +913,9 @@
devolver un string desde una ruta, el cuerpo de la respuesta no va a estar
disponible en un filtro after, debido a que todavía no se ha generado.</p>
-<p>Los filtros aceptan un patrón opcional, que cuando está presente causa que
-los mismos sean evaluados únicamente si el path de la petición coincide con
-ese patrón:</p>
+<p>Los filtros aceptan un patrón opcional, que cuando está presente causa
+que los mismos sean evaluados únicamente si el path de la petición
+coincide con ese patrón:</p>
<pre>before '/protegido/*' do
autenticar!
@@ -936,8 +938,9 @@
<a name='Ayudantes'></a>
<h2>Ayudantes</h2>
-<p>Usá el método top-level <tt>helpers</tt> para definir métodos ayudantes que
-pueden ser utilizados dentro de los manejadores de rutas y las plantillas:</p>
+<p>Usá el método top-level <tt>helpers</tt> para definir métodos ayudantes
+que pueden ser utilizados dentro de los manejadores de rutas y las
+plantillas:</p>
<pre>helpers do
def bar(nombre)
@@ -949,6 +952,22 @@
bar(params[:nombre])
end</pre>
+<p>Por cuestiones organizativas, puede resultar conveniente organizar los
+métodos ayudantes en distintos módulos:</p>
+
+<pre>module FooUtils
+ def foo(nombre) &quot;#{nombre}foo&quot; end
+end
+
+module BarUtils
+ def bar(nombre) &quot;#{nombre}bar&quot; end
+end
+
+helpers FooUtils, BarUtils</pre>
+
+<p>El efecto de utilizar <tt>helpers</tt> de esta manera es el mismo que
+resulta de incluir los módulos en la clase de la aplicación.</p>
+
<a name='Usando%20Sesiones'></a>
<h3>Usando Sesiones</h3>
@@ -986,14 +1005,14 @@
<p>Para incrementar la seguridad, los datos de la sesión almacenados en la
cookie son firmados con un secreto de sesión. Este secreto, es generado
aleatoriamente por Sinatra. De cualquier manera, hay que tener en cuenta
-que cada vez que inicies la aplicación se va a generar uno nuevo. Así, si
-querés que todas las instancias de tu aplicación compartan un único
+que cada vez que inicies la aplicación se va a generar uno nuevo. Así,
+si querés que todas las instancias de tu aplicación compartan un único
secreto, tenés que definirlo vos:</p>
<pre>set :session_secret, 'super secreto'</pre>
-<p>Si necesitás una configuración más específica, <tt>sessions</tt> acepta un
-Hash con opciones:</p>
+<p>Si necesitás una configuración más específica, <tt>sessions</tt> acepta
+un Hash con opciones:</p>
<pre>set :sessions, :domain =&gt; 'foo.com'</pre>
@@ -1064,8 +1083,9 @@
<tt>/bar</tt>. Así, vas a simplificar las pruebas y a mejorar el
rendimiento.</p>
-<p>Si querés que la petición se envíe a la misma instancia de la aplicación en
-lugar de a otra, usá <tt>call!</tt> en lugar de <tt>call</tt>.</p>
+<p>Si querés que la petición se envíe a la misma instancia de la
+aplicación en lugar de a otra, usá <tt>call!</tt> en lugar de
+<tt>call</tt>.</p>
<p>En la especificación de Rack podés encontrar más información sobre
<tt>call</tt>.</p>
@@ -1073,11 +1093,12 @@
<a name='Asignando%20el%20C%C3%B3digo%20de%20Estado,%20los%20Encabezados%20y%20el%20Cuerpo%20de%20una%20Respuesta'></a>
<h3>Asignando el Código de Estado, los Encabezados y el Cuerpo de una Respuesta</h3>
-<p>Es posible, y se recomienda, asignar el código de estado y el cuerpo de una
-respuesta con el valor de retorno de una ruta. De cualquier manera, en
+<p>Es posible, y se recomienda, asignar el código de estado y el cuerpo de
+una respuesta con el valor de retorno de una ruta. De cualquier manera, en
varios escenarios, puede que sea conveniente asignar el cuerpo en un punto
-arbitrario del flujo de ejecución con el método <tt>body</tt>. A partir de
-ahí, podés usar ese mismo método para acceder al cuerpo de la respuesta:</p>
+arbitrario del flujo de ejecución con el método <tt>body</tt>. A partir
+de ahí, podés usar ese mismo método para acceder al cuerpo de la
+respuesta:</p>
<pre>get '/foo' do
body &quot;bar&quot;
@@ -1089,9 +1110,10 @@
<p>También es posible pasarle un bloque a <tt>body</tt>, que será ejecutado
por el Rack handler (podés usar esto para implementar streaming, mirá
-Valores de retorno).</p>
+"Valores de retorno").</p>
-<p>De manera similar, también podés asignar el código de estado y encabezados:</p>
+<p>De manera similar, también podés asignar el código de estado y
+encabezados:</p>
<pre>get '/foo' do
status 418
@@ -1111,8 +1133,8 @@
<p>A veces vas a querer empezar a enviar la respuesta a pesar de que todavía
no terminaste de generar su cuerpo. También es posible que, en algunos
casos, quieras seguir enviando información hasta que el cliente cierre la
-conexión. Cuando esto ocurra, el <tt>stream</tt> helper te va a ser de gran
-ayuda:</p>
+conexión. Cuando esto ocurra, el <tt>stream</tt> helper te va a ser de
+gran ayuda:</p>
<pre>get '/' do
stream do |out|
@@ -1163,15 +1185,15 @@
<a name='Log%20(Registro)'></a>
<h3>Log (Registro)</h3>
-<p>En el ámbito de la petición, el helper <tt>logger</tt> (registrador) expone
-una instancia de <tt>Logger</tt>:</p>
+<p>En el ámbito de la petición, el helper <tt>logger</tt> (registrador)
+expone una instancia de <tt>Logger</tt>:</p>
<pre>get '/' do
logger.info &quot;cargando datos&quot;
# ...
end</pre>
-<p>Este logger tiene en cuenta la configuración de logueo de tu Rack handler.
+<p>Este logger tiene en cuenta la configuración de logueo de tu Rack handler.
Si el logueo está desactivado, este método va a devolver un objeto que se
comporta como un logger pero que en realidad no hace nada. Así, no vas a
tener que preocuparte por esta situación.</p>
@@ -1188,8 +1210,8 @@
<p>Para evitar que se inicialice cualquier middleware de logging, configurá
<tt>logging</tt> a <tt>nil</tt>. Tené en cuenta que, cuando hagas esto,
-<tt>logger</tt> va a devolver <tt>nil</tt>. Un caso común es cuando querés
-usar tu propio logger. Sinatra va a usar lo que encuentre en
+<tt>logger</tt> va a devolver <tt>nil</tt>. Un caso común es cuando
+querés usar tu propio logger. Sinatra va a usar lo que encuentre en
<tt>env['rack.logger']</tt>.</p>
<a name='Tipos%20Mime'></a>
@@ -1221,8 +1243,8 @@
<p>Tiene en cuenta proxies inversos y encaminadores de Rack, si están
presentes.</p>
-<p>Este método también puede invocarse mediante su alias <tt>to</tt> (mirá un
-ejemplo a continuación).</p>
+<p>Este método también puede invocarse mediante su alias <tt>to</tt> (mirá
+un ejemplo a continuación).</p>
<a name='Redirecci%C3%B3n%20del%20Navegador'></a>
<h3>Redirección del Navegador</h3>
@@ -1251,8 +1273,8 @@
redirect back
end</pre>
-<p>Para pasar argumentos con una redirección, podés agregarlos a la cadena de
-búsqueda:</p>
+<p>Para pasar argumentos con una redirección, podés agregarlos a la cadena
+de búsqueda:</p>
<pre>redirect to('/bar?suma=42')</pre>
@@ -1334,8 +1356,8 @@
encabezado <tt>Cache-Control</tt> a archivos estáticos (ver la sección de
configuración para más detalles).</p>
-<p>De acuerdo con la RFC 2616 tu aplicación debería comportarse diferente si a
-las cabeceras If-Match o If-None-Match se le asigna el valor <tt>*</tt>
+<p>De acuerdo con la RFC 2616 tu aplicación debería comportarse diferente si
+a las cabeceras If-Match o If-None-Match se le asigna el valor <tt>*</tt>
cuando el recurso solicitado ya existe. Sinatra asume para peticiones
seguras (como get) e idempotentes (como put) que el recurso existe,
mientras que para el resto (como post), que no. Podes cambiar este
@@ -1368,7 +1390,7 @@
<p>Estas opciones son:</p>
<dl class="rdoc-list"><dt>filename</dt>
<dd>
-<p>nombre del archivo respondido, por defecto es el nombre real del archivo.</p>
+<p>nombre del archivo devuelto, por defecto es el nombre real del archivo.</p>
</dd><dt>last_modified</dt>
<dd>
<p>valor para el encabezado Last-Modified, por defecto toma el mtime del
@@ -1449,8 +1471,9 @@
<a name='Archivos%20Adjuntos'></a>
<h3>Archivos Adjuntos</h3>
-<p>Podés usar el método helper <tt>attachment</tt> para indicarle al navegador
-que almacene la respuesta en el disco en lugar de mostrarla en pantalla:</p>
+<p>Podés usar el método helper <tt>attachment</tt> para indicarle al
+navegador que almacene la respuesta en el disco en lugar de mostrarla en
+pantalla:</p>
<pre>get '/' do
attachment
@@ -1508,9 +1531,9 @@
puts &quot;podría ser #{archivo}&quot;
end</pre>
-<p>Si bien esto no es muy útil, lo interesante es que podés sobreescribir este
-método, y así enganchar tu propio mecanismo de búsqueda. Por ejemplo, para
-poder utilizar más de un directorio de vistas:</p>
+<p>Si bien esto no es muy útil, lo interesante es que podés sobreescribir
+este método, y así enganchar tu propio mecanismo de búsqueda. Por
+ejemplo, para poder utilizar más de un directorio de vistas:</p>
<pre>set :views, ['vistas', 'plantillas']
@@ -1535,13 +1558,13 @@
<p>¡Es muy fácil convertir estos ejemplos en una extensión y compartirla!.</p>
-<p>Notá que <tt>find_template</tt> no verifica si un archivo existe realmente,
-sino que llama al bloque que recibe para cada path posible. Esto no
-representa un problema de rendimiento debido a que <tt>render</tt> va a
-usar <tt>break</tt> ni bien encuentre un archivo que exista. Además, las
-ubicaciones de las plantillas (y su contenido) se cachean cuando no estás
-en el modo de desarrollo. Es bueno tener en cuenta lo anteiror si escribís
-un método medio loco.</p>
+<p>Notá que <tt>find_template</tt> no verifica si un archivo existe
+realmente, sino que llama al bloque que recibe para cada path posible.
+Esto no representa un problema de rendimiento debido a que <tt>render</tt>
+va a usar <tt>break</tt> ni bien encuentre un archivo que exista. Además,
+las ubicaciones de las plantillas (y su contenido) se cachean cuando no
+estás en el modo de desarrollo. Es bueno tener en cuenta lo anteiror si
+escribís un método medio loco.</p>
<a name='Configuraci%C3%B3n'></a>
<h2>Configuración</h2>
@@ -1595,8 +1618,8 @@
<p>Sinatra usa <a
href="https://github.com/rkh/rack-protection#readme">Rack::Protection</a>
-para defender a tu aplicación de los ataques más comunes. Tenés que tener
-en cuenta que como consecuencia de esto puede venir asociada una
+para defender a tu aplicación de los ataques más comunes. Tenés que
+tener en cuenta que como consecuencia de esto puede venir asociada una
disminución del rendimiento de tu aplicación. Si por este, o algún otro
motivo, querés desactivar está funcionalidad, podés hacerlo:</p>
@@ -1618,10 +1641,10 @@
embargo, como consecuencia de esto, va a dejar de cumplir con el RFC 2616
(HTTP 1.1), que solamente permite redirecciones absolutas.</p>
-<p>Activalo si tu apliación está corriendo atrás de un proxy inverso que no se
-ha configurado adecuadamente. Notá que el helper <tt>url</tt> va a seguir
-produciendo URLs absolutas, a menos que le pasés <tt>false</tt> como
-segundo parámetro.</p>
+<p>Activalo si tu apliación está corriendo atrás de un proxy inverso que no
+se ha configurado adecuadamente. Notá que el helper <tt>url</tt> va a
+seguir produciendo URLs absolutas, a menos que le pasés <tt>false</tt>
+como segundo parámetro.</p>
<p>Deshabilitada por defecto.</p>
</dd><dt>add_charsets</dt>
@@ -1629,15 +1652,15 @@
<p>tipos mime a los que el helper <tt>content_type</tt> les añade
automáticamente el charset.</p>
-<p>En general, no deberías asignar directamente esta opción, sino añadirle los
-charsets que quieras:</p>
+<p>En general, no deberías asignar directamente esta opción, sino añadirle
+los charsets que quieras:</p>
<pre>settings.add_charsets &lt;&lt; &quot;application/foobar&quot;</pre>
</dd><dt>app_file</dt>
<dd>
<p>path del archivo principal de la aplicación, se utiliza para detectar la
-raíz del proyecto, el directorio de las vistas y el público, así como las
-plantillas inline.</p>
+raíz del proyecto, el directorio de las vistas y el público, así como
+las plantillas inline.</p>
</dd><dt>bind</dt>
<dd>
<p>dirección IP que utilizará el servidor integrado (por defecto: 0.0.0.0).</p>
@@ -1672,9 +1695,9 @@
</dd><dt>prefixed_redirects</dt>
<dd>
<p>define si inserta <tt>request.script_name</tt> en las redirecciones cuando
-no se proporciona un path absoluto. De esta manera, cuando está habilitada,
-<tt>redirect '/foo'</tt> se comporta de la misma manera que <tt>redirect
-to('/foo')</tt>. Se encuentra deshabilitada por defecto.</p>
+no se proporciona un path absoluto. De esta manera, cuando está
+habilitada, <tt>redirect '/foo'</tt> se comporta de la misma manera que
+<tt>redirect to('/foo')</tt>. Se encuentra deshabilitada por defecto.</p>
</dd><dt>protection</dt>
<dd>
<p>define si deben activarse las protecciones para los ataques web más
@@ -1693,8 +1716,8 @@
<p>Se encuentra activado en el entorno de desarrollo.</p>
</dd><dt>root</dt>
<dd>
-<p>path del directorio raíz del proyecto. Si no está presente, se infiere del
-valor de la opción <tt>app_file</tt>.</p>
+<p>path del directorio raíz del proyecto. Si no está presente, se infiere
+del valor de la opción <tt>app_file</tt>.</p>
</dd><dt>raise_errors</dt>
<dd>
<p>elevar excepciones (detiene la aplicación). Se encuentra activada por
@@ -1711,12 +1734,12 @@
</dd><dt>server</dt>
<dd>
<p>servidor, o lista de servidores, para usar como servidor integrado. Por
-defecto: [thin’, ‘mongrel’, ‘webrick], el orden establece la prioridad.</p>
+defecto: ['thin', 'mongrel', 'webrick'], el orden establece la prioridad.</p>
</dd><dt>sessions</dt>
<dd>
<p>habilita el soporte de sesiones basadas en cookies a través de
-<tt>Rack::Session::Cookie</tt>. Ver la sección Usando Sesiones para más
-información.</p>
+<tt>Rack::Session::Cookie</tt>. Ver la sección 'Usando Sesiones' para
+más información.</p>
</dd><dt>show_exceptions</dt>
<dd>
<p>muestra un stack trace en el navegador cuando ocurre una excepción. Se
@@ -1726,9 +1749,9 @@
<dd>
<p>define si Sinatra debe encargarse de servir archivos estáticos.</p>
-<p>Deshabilitala cuando usés un servidor capaz de hacerlo por sí solo, porque
-mejorará el rendimiento. Se encuentra habilitada por defecto en el estilo
-clásico y desactivado en el el modular.</p>
+<p>Deshabilitala cuando usés un servidor capaz de hacerlo por sí solo,
+porque mejorará el rendimiento. Se encuentra habilitada por defecto en el
+estilo clásico y desactivado en el el modular.</p>
</dd><dt>static_cache_control</dt>
<dd>
<p>cuando Sinatra está sirviendo archivos estáticos, y está opción está
@@ -1743,6 +1766,33 @@
valor de la opción <tt>app_file</tt>.</p>
</dd></dl>
+<a name='Entornos'></a>
+<h2>Entornos</h2>
+
+<p>Existen tres entornos (<tt>environments</tt>) predefinidos:
+<tt>development</tt>, <tt>production</tt> y <tt>test</tt>. El entorno por
+defecto es <tt>development</tt> y tiene algunas particularidades:</p>
+<ul><li>
+<p>Se recargan las plantillas entre una petición y la siguiente, a diferencia</p>
+</li></ul>
+
+<p>de <tt>production</tt> y <tt>test</tt>, donde se cachean.</p>
+<ul><li>
+<p>Se instalan manejadores de errores <tt>not_found</tt> y <tt>error</tt></p>
+</li></ul>
+
+<p>especiales que muestran un stack trace en el navegador cuando son
+disparados.</p>
+
+<p>Para utilizar alguno de los otros entornos puede asignarse el valor
+correspondiente a la variable de entorno <tt>RACK_ENV</tt>, o bien utilizar
+la opción <tt>-e</tt> al ejecutar la aplicación:</p>
+
+<pre>ruby mi_app.rb -e &lt;ENTORNO&gt;</pre>
+
+<p>Los métodos <tt>development?</tt>, <tt>test?</tt> y <tt>production?</tt>
+te permiten conocer el entorno actual.</p>
+
<a name='Manejo%20de%20Errores'></a>
<h2>Manejo de Errores</h2>
@@ -1787,7 +1837,8 @@
<pre>Lo que pasó fue... algo malo</pre>
-<p>También, podés instalar un manejador de errores para un código de estado:</p>
+<p>También, podés instalar un manejador de errores para un código de
+estado:</p>
<pre>error 403 do
'Acceso prohibido'
@@ -1805,7 +1856,7 @@
<p>Sinatra instala manejadores <tt>not_found</tt> y
&lt;tt&gt;error&lt;/ttt&gt; especiales cuando se ejecuta dentro del entorno
-de desarrollo development.</p>
+de desarrollo "development".</p>
<a name='Rack%20Middleware'></a>
<h2>Rack Middleware</h2>
@@ -1813,10 +1864,10 @@
<p>Sinatra corre sobre <a href="http://rack.rubyforge.org/">Rack</a>, una
interfaz minimalista que es un estándar para frameworks webs escritos en
Ruby. Una de las capacidades más interesantes de Rack para los
-desarrolladores de aplicaciones es el soporte de middleware” – componentes
-que se ubican entre el servidor y tu aplicación, supervisando y/o
-manipulando la petición/respuesta HTTP para proporcionar varios tipos de
-funcionalidades comunes.</p>
+desarrolladores de aplicaciones es el soporte de "middleware" --
+componentes que se ubican entre el servidor y tu aplicación, supervisando
+y/o manipulando la petición/respuesta HTTP para proporcionar varios tipos
+de funcionalidades comunes.</p>
<p>Sinatra hace muy sencillo construir tuberías de Rack middleware a través
del método top-level <tt>use</tt>:</p>
@@ -1831,7 +1882,8 @@
'Hola Mundo'
end</pre>
-<p>Las semánticas de <tt>use</tt> son idénticas a las definidas para el DSL <a
+<p>Las semánticas de <tt>use</tt> son idénticas a las definidas para el DSL
+<a
href="http://rack.rubyforge.org/doc/classes/Rack/Builder.html">Rack::Builder</a>
(más frecuentemente usado desde archivos rackup). Por ejemplo, el método
<tt>use</tt> acepta argumentos múltiples/variables así como bloques:</p>
@@ -1843,8 +1895,8 @@
<p>Rack es distribuido con una variedad de middleware estándar para logging,
debugging, enrutamiento URL, autenticación, y manejo de sesiones. Sinatra
usa muchos de estos componentes automáticamente de acuerdo a su
-configuración para que típicamente no tengas que usarlas (con <tt>use</tt>)
-explícitamente.</p>
+configuración para que típicamente no tengas que usarlas (con
+<tt>use</tt>) explícitamente.</p>
<p>Podés encontrar middleware útil en <a
href="https://github.com/rack/rack/tree/master/lib/rack">rack</a>, <a
@@ -1890,15 +1942,15 @@
<a name='Sinatra::Base%20-%20Middleware,%20Librer%C3%ADas,%20y%20Aplicaciones%20Modulares'></a>
<h2>Sinatra::Base - Middleware, Librerías, y Aplicaciones Modulares</h2>
-<p>Definir tu aplicación en el top-level funciona bien para micro-aplicaciones
-pero trae inconvenientes considerables a la hora de construir componentes
-reutilizables como Rack middleware, Rails metal, simple librerías con un
-componente de servidor, o incluso extensiones de Sinatra. El DSL de
-top-level contamina el espacio de nombres de Object y asume una
-configuración apropiada para micro-aplicaciones (por ejemplo, un único
-archivo de aplicación, los directorios <tt>./public</tt> y
-<tt>./views</tt>, logging, página con detalles de excepción, etc.). Ahí es
-donde <tt>Sinatra::Base</tt> entra en el juego:</p>
+<p>Definir tu aplicación en el top-level funciona bien para
+micro-aplicaciones pero trae inconvenientes considerables a la hora de
+construir componentes reutilizables como Rack middleware, Rails metal,
+simple librerías con un componente de servidor, o incluso extensiones de
+Sinatra. El DSL de top-level contamina el espacio de nombres de Object y
+asume una configuración apropiada para micro-aplicaciones (por ejemplo, un
+único archivo de aplicación, los directorios <tt>./public</tt> y
+<tt>./views</tt>, logging, página con detalles de excepción, etc.). Ahí
+es donde <tt>Sinatra::Base</tt> entra en el juego:</p>
<pre>require 'sinatra/base'
@@ -1912,20 +1964,21 @@
end</pre>
<p>Las subclases de <tt>Sinatra::Base</tt> tienen disponibles exactamente los
-mismos métodos que los provistos por el DSL de top-level. La mayoría de las
-aplicaciones top-level se pueden convertir en componentes
+mismos métodos que los provistos por el DSL de top-level. La mayoría de
+las aplicaciones top-level se pueden convertir en componentes
<tt>Sinatra::Base</tt> con dos modificaciones:</p>
<ul><li>
<p>Tu archivo debe requerir <tt>sinatra/base</tt> en lugar de
<tt>sinatra</tt>; de otra manera, todos los métodos del DSL de sinatra son
importados dentro del espacio de nombres principal.</p>
</li><li>
-<p>Poné las rutas, manejadores de errores, filtros y opciones de tu aplicación
-en una subclase de <tt>Sinatra::Base</tt>.</p>
+<p>Poné las rutas, manejadores de errores, filtros y opciones de tu
+aplicación en una subclase de <tt>Sinatra::Base</tt>.</p>
</li></ul>
-<p><tt>Sinatra::Base</tt> es una pizarra en blanco. La mayoría de las opciones
-están desactivadas por defecto, incluyendo el servidor incorporado. Mirá <a
+<p><tt>Sinatra::Base</tt> es una pizarra en blanco. La mayoría de las
+opciones están desactivadas por defecto, incluyendo el servidor
+incorporado. Mirá <a
href="http://sinatra.github.com/configuration.html">Opciones y
Configuraciones</a> para detalles sobre las opciones disponibles y su
comportamiento.</p>
@@ -1934,8 +1987,8 @@
<h3>Estilo Modular vs. Clásico</h3>
<p>Contrariamente a la creencia popular, no hay nada de malo con el estilo
-clásico. Si se ajusta a tu aplicación, no es necesario que la cambies a una
-modular.</p>
+clásico. Si se ajusta a tu aplicación, no es necesario que la cambies a
+una modular.</p>
<p>Existen tan solo dos desventajas en comparación con el estilo modular:</p>
<ul><li>
@@ -1943,15 +1996,15 @@
planificado usar más, cambiá al estilo modular.</p>
</li><li>
<p>El estilo clásico contamina Object con métodos delegadores - si tenés
-planificado empaquetar tu aplicación en una librería/gem, cambiá al estilo
-modular.</p>
+planificado empaquetar tu aplicación en una librería/gem, cambiá al
+estilo modular.</p>
</li></ul>
<p>No hay ninguna razón por la cuál no puedas mezclar los estilos modular y
clásico.</p>
-<p>Cuando cambiés de un estilo al otro, tené en cuenta las sutiles diferencias
-entre sus configuraciones:</p>
+<p>Cuando cambiés de un estilo al otro, tené en cuenta las sutiles
+diferencias entre sus configuraciones:</p>
<pre>Configuración Clásica Modular
@@ -2015,8 +2068,8 @@
<p>Indicadores de que probablemente querés usar <tt>config.ru</tt>:</p>
<ul><li>
-<p>Querés realizar el deploy con un hanlder Rack distinto (Passenger, Unicorn,
-Heroku, ).</p>
+<p>Querés realizar el deploy con un hanlder Rack distinto (Passenger,
+Unicorn, Heroku, ...).</p>
</li><li>
<p>Querés usar más de una subclase de <tt>Sinatra::Base</tt>.</p>
</li><li>
@@ -2031,9 +2084,9 @@
<h3>Utilizando Sinatra como Middleware</h3>
<p>Sinatra no solo es capaz de usar otro Rack middleware, sino que a su vez,
-cualquier aplicación Sinatra puede ser agregada delante de un endpoint Rack
-como middleware. Este endpoint puede ser otra aplicación Sinatra, o
-cualquier aplicación basada en Rack (Rails/Ramaze/Camping/):</p>
+cualquier aplicación Sinatra puede ser agregada delante de un endpoint
+Rack como middleware. Este endpoint puede ser otra aplicación Sinatra, o
+cualquier aplicación basada en Rack (Rails/Ramaze/Camping/...):</p>
<pre>require 'sinatra/base'
@@ -2109,16 +2162,16 @@
<a name='%C3%81mbitos%20y%20Ligaduras'></a>
<h2>Ámbitos y Ligaduras</h2>
-<p>El ámbito en el que te encontrás determina que métodos y variables están
-disponibles.</p>
+<p>El ámbito en el que te encontrás determina que métodos y variables
+están disponibles.</p>
<a name='%C3%81mbito%20de%20Aplicaci%C3%B3n/Clase'></a>
<h3>Ámbito de Aplicación/Clase</h3>
-<p>Cada aplicación Sinatra es una subclase de <tt>Sinatra::Base</tt>. Si estás
-usando el DSL de top-level (<tt>require 'sinatra'</tt>), entonces esta
-clase es <tt>Sinatra::Application</tt>, de otra manera es la subclase que
-creaste explícitamente. Al nivel de la clase tenés métodos como
+<p>Cada aplicación Sinatra es una subclase de <tt>Sinatra::Base</tt>. Si
+estás usando el DSL de top-level (<tt>require 'sinatra'</tt>), entonces
+esta clase es <tt>Sinatra::Application</tt>, de otra manera es la subclase
+que creaste explícitamente. Al nivel de la clase tenés métodos como
<tt>get</tt> o <tt>before</tt>, pero no podés acceder a los objetos
<tt>request</tt> o <tt>session</tt>, ya que hay una única clase de la
aplicación para todas las peticiones.</p>
@@ -2149,8 +2202,8 @@
<p>Este ámbito puede alcanzarse de las siguientes maneras:</p>
<ul><li>
-<p>A través del objeto pasado a los bloques de configuración (<tt>configure {
-|c| ...}</tt>)</p>
+<p>A través del objeto pasado a los bloques de configuración (<tt>configure
+{ |c| ...}</tt>)</p>
</li><li>
<p>Llamando a <tt>settings</tt> desde dentro del ámbito de la petición</p>
</li></ul>
@@ -2161,9 +2214,9 @@
<p>Para cada petición entrante, una nueva instancia de la clase de tu
aplicación es creada y todos los bloques de rutas son ejecutados en ese
ámbito. Desde este ámbito podés acceder a los objetos <tt>request</tt> y
-<tt>session</tt> o llamar a los métodos de renderización como <tt>erb</tt>
-o <tt>haml</tt>. Podés acceder al ámbito de la aplicación desde el ámbito
-de la petición utilizando <tt>settings</tt>:</p>
+<tt>session</tt> o llamar a los métodos de renderización como
+<tt>erb</tt> o <tt>haml</tt>. Podés acceder al ámbito de la aplicación
+desde el ámbito de la petición utilizando <tt>settings</tt>:</p>
<pre>class MiApp &lt; Sinatra::Base
# Ey, estoy en el ámbito de la aplicación!
@@ -2196,11 +2249,11 @@
<p>El ámbito de delegación solo reenvía métodos al ámbito de clase. De
cualquier manera, no se comporta 100% como el ámbito de clase porque no
-tenés la ligadura de la clase: únicamente métodos marcados explícitamente
-para delegación están disponibles y no compartís variables/estado con el
-ámbito de clase (léase: tenés un <tt>self</tt> diferente). Podés agregar
-delegaciones de método llamando a <tt>Sinatra::Delegator.delegate
-:nombre_del_metodo</tt>.</p>
+tenés la ligadura de la clase: únicamente métodos marcados
+explícitamente para delegación están disponibles y no compartís
+variables/estado con el ámbito de clase (léase: tenés un <tt>self</tt>
+diferente). Podés agregar delegaciones de método llamando a
+<tt>Sinatra::Delegator.delegate :nombre_del_metodo</tt>.</p>
<p>Tenés la ligadura al ámbito de delegación dentro de:</p>
<ul><li>
@@ -2239,14 +2292,14 @@
<dd>
<p>1.8.7 es soportado completamente. Sin embargo, si no hay nada que te lo
prohíba, te recomendamos que usés 1.9.2 o cambies a JRuby o Rubinius. No
-se dejará de dar soporte a 1.8.7 hasta Sinatra 2.0 y Ruby 2.0, aunque si se
-libera la versión 1.8.8 de Ruby las cosas podrían llegar a cambiar. Sin
-embargo, que eso ocurra es muy poco probable, e incluso el caso de que lo
-haga, puede que se siga dando soporte a 1.8.7. <b>Hemos dejado de soportar
-Ruby 1.8.6.</b> Si querés ejecutar Sinatra sobre 1.8.6, podés utilizar la
-versión 1.2, pero tené en cuenta que una vez que Sinatra 1.4.0 sea
-liberado, ya no se corregirán errores por más que se reciban reportes de
-los mismos.</p>
+se dejará de dar soporte a 1.8.7 hasta Sinatra 2.0 y Ruby 2.0, aunque si
+se libera la versión 1.8.8 de Ruby las cosas podrían llegar a cambiar.
+Sin embargo, que eso ocurra es muy poco probable, e incluso el caso de que
+lo haga, puede que se siga dando soporte a 1.8.7. <b>Hemos dejado de
+soportar Ruby 1.8.6.</b> Si querés ejecutar Sinatra sobre 1.8.6, podés
+utilizar la versión 1.2, pero tené en cuenta que una vez que Sinatra
+1.4.0 sea liberado, ya no se corregirán errores por más que se reciban
+reportes de los mismos.</p>
</dd><dt> Ruby 1.9.2 </dt>
<dd>
<p>1.9.2 es soportado y recomendado. Tené en cuenta que Radius y Markaby no
@@ -2259,13 +2312,13 @@
<dd>
<p>1.9.3 es soportado completamente. De todas maneras, recomendamos esperar a
que se liberen niveles de parche superiores (el actual es p0) antes de
-usarlo en producción. Es importante notar que el cambio desde una versión
-anterior a 1.9.3 va a invalidar todas las sesiones.</p>
+usarlo en producción. Es importante notar que el cambio desde una
+versión anterior a 1.9.3 va a invalidar todas las sesiones.</p>
</dd><dt> Rubinius </dt>
<dd>
<p>Rubinius es soportado oficialmente (Rubinius &gt;= 1.2.4). Todo funciona
-correctamente, incluyendo los lenguajes de plantillas. La próxima versión,
-2.0, también es soportada.</p>
+correctamente, incluyendo los lenguajes de plantillas. La próxima
+versión, 2.0, también es soportada.</p>
</dd><dt> JRuby </dt>
<dd>
<p>JRuby es soportado oficialmente (JRuby &gt;= 1.6.5). No se conocen
@@ -2294,10 +2347,10 @@
rompen ahí y no en una plataforma soportada, asumimos que no es nuestro
problema sino el suyo.</p>
-<p>Nuestro servidor CI también se ejecuta sobre ruby-head (que será la próxima
-versión 2.0.0) y la rama 1.9.4. Como están en movimiento constante, no
-podemos garantizar nada. De todas formas, podés contar con que tanto
-1.9.4-p0 como 2.0.0-p0 sea soportadas.</p>
+<p>Nuestro servidor CI también se ejecuta sobre ruby-head (que será la
+próxima versión 2.0.0) y la rama 1.9.4. Como están en movimiento
+constante, no podemos garantizar nada. De todas formas, podés contar con
+que tanto 1.9.4-p0 como 2.0.0-p0 sea soportadas.</p>
<p>Sinatra debería funcionar en cualquier sistema operativo soportado por la
implementación de Ruby elegida.</p>
@@ -2308,8 +2361,9 @@
<a name='A%20la%20Vanguardia'></a>
<h2>A la Vanguardia</h2>
-<p>Si querés usar el código de Sinatra más reciente, sentite libre de ejecutar
-tu aplicación sobre la rama master, en general es bastante estable.</p>
+<p>Si querés usar el código de Sinatra más reciente, sentite libre de
+ejecutar tu aplicación sobre la rama master, en general es bastante
+estable.</p>
<p>También liberamos prereleases de vez en cuando, así, podés hacer</p>
@@ -2327,7 +2381,8 @@
<pre>gem install bundler</pre>
-<p>Después, en el directorio de tu proyecto, creá un archivo <tt>Gemfile</tt>:</p>
+<p>Después, en el directorio de tu proyecto, creá un archivo
+<tt>Gemfile</tt>:</p>
<pre>source :rubygems
gem 'sinatra', :git =&gt; &quot;git://github.com/sinatra/sinatra.git&quot;
@@ -2347,8 +2402,8 @@
<a name='Con%20Git'></a>
<h3>Con Git</h3>
-<p>Cloná el repositorio localmente y ejecutá tu aplicación, asegurándote que
-el directorio <tt>sinatra/lib</tt> esté en el <tt>$LOAD_PATH</tt>:</p>
+<p>Cloná el repositorio localmente y ejecutá tu aplicación, asegurándote
+que el directorio <tt>sinatra/lib</tt> esté en el <tt>$LOAD_PATH</tt>:</p>
<pre>cd miapp
git clone git://github.com/sinatra/sinatra.git
@@ -2406,9 +2461,9 @@
contribuidas por la comunidad (en inglés).</p>
</li><li>
<p>Documentación de la API para la <a
-href="http://rubydoc.info/gems/sinatra">última versión liberada</a> o para
-la <a href="http://rubydoc.info/github/sinatra/sinatra">rama de desarrollo
-actual</a> en <a href="http://rubydoc.info">rubydoc.info</a>/</p>
+href="http://rubydoc.info/gems/sinatra">última versión liberada</a> o
+para la <a href="http://rubydoc.info/github/sinatra/sinatra">rama de
+desarrollo actual</a> en <a href="http://rubydoc.info">rubydoc.info</a>/</p>
</li><li>
<p><a href="http://ci.rkh.im/view/Sinatra/">Servidor de IC</a></p>
</li></ul>
734 _includes/README.fr.html
View
@@ -48,15 +48,17 @@
<li><a href='#Redirection%20du%20navigateur'>Redirection du navigateur</a></li>
<li><a href='#Contr%C3%B4le%20du%20cache'>Contrôle du cache</a></li>
<li><a href='#Envoyer%20des%20fichiers'>Envoyer des fichiers</a></li>
- <li><a href='#Acc%C3%A9der%20%C3%A0%20l%E2%80%99objet%20requ%C3%AAte'>Accéder à lobjet requête</a></li>
+ <li><a href='#Acc%C3%A9der%20%C3%A0%20l'objet%20requ%C3%AAte'>Accéder à l'objet requête</a></li>
<li><a href='#Fichiers%20joints'>Fichiers joints</a></li>
<li><a href='#G%C3%A9rer%20Date%20et%20Time'>Gérer Date et Time</a></li>
<li><a href='#Chercher%20les%20fichiers%20de%20templates'>Chercher les fichiers de templates</a></li>
</ol>
<li><a href='#Configuration'>Configuration</a></li>
<ol class='level-2'>
+ <li><a href='#Se%20prot%C3%A9ger%20des%20attaques'>Se protéger des attaques</a></li>
<li><a href='#Param%C3%A8tres%20disponibles'>Paramètres disponibles</a></li>
</ol>
+ <li><a href='#Environements'>Environements</a></li>
<li><a href='#G%C3%A9rer%20les%20erreurs'>Gérer les erreurs</a></li>
<ol class='level-2'>
<li><a href='#NotFound'>NotFound</a></li>
@@ -71,11 +73,11 @@
<li><a href='#Utiliser%20une%20application%20de%20style%20classique%20avec%20un%20fichier%20config.ru'>Utiliser une application de style classique avec un fichier config.ru</a></li>
<li><a href='#Quand%20utiliser%20un%20fichier%20config.ru%20?'>Quand utiliser un fichier config.ru ?</a></li>
<li><a href='#Utiliser%20Sinatra%20comme%20Middleware'>Utiliser Sinatra comme Middleware</a></li>
- <li><a href='#Cr%C3%A9ation%20dynamique%20d%E2%80%99applications'>Création dynamique dapplications</a></li>
+ <li><a href='#Cr%C3%A9ation%20dynamique%20d'applications'>Création dynamique d'applications</a></li>
</ol>
<li><a href='#Contextes%20et%20Binding'>Contextes et Binding</a></li>
<ol class='level-2'>
- <li><a href='#Contexte%20de%20l%E2%80%99application/classe'>Contexte de lapplication/classe</a></li>
+ <li><a href='#Contexte%20de%20l'application/classe'>Contexte de l'application/classe</a></li>
<li><a href='#Contexte%20de%20la%20requ%C3%AAte/instance'>Contexte de la requête/instance</a></li>
<li><a href='#Le%20contexte%20de%20d%C3%A9l%C3%A9gation'>Le contexte de délégation</a></li>
</ol>
@@ -95,10 +97,10 @@
<p>= Sinatra</p>
<p><em>Attention : Ce document correspond à la traduction de la version
-anglaise et il nest peut être plus à jour.</em></p>
+anglaise et il n'est peut être plus à jour.</em></p>
-<p>Sinatra est un DSL pour créer rapidement et facilement des applications web
-en Ruby :</p>
+<p>Sinatra est un DSL pour créer rapidement et facilement des applications
+web en Ruby :</p>
<pre># mon_application.rb
require 'sinatra'
@@ -115,14 +117,14 @@
<p>Le résultat est visible sur : <a
href="http://localhost:4567">localhost:4567</a></p>
-<p>Il est recommandé dexécuter également <tt>gem install thin</tt>, pour que
-Sinatra utilise le server Thin quand il est disponible.</p>
+<p>Il est recommandé d'exécuter également <tt>gem install thin</tt>, pour
+que Sinatra utilise le server Thin quand il est disponible.</p>
<a name='Routes'></a>
<h2>Routes</h2>
-<p>Dans Sinatra, une route est une méthode HTTP couplée à un masque (pattern)
-URL. Chaque route est associée à un bloc :</p>
+<p>Dans Sinatra, une route est une méthode HTTP couplée à un masque
+(pattern) URL. Chaque route est associée à un bloc :</p>
<pre>get '/' do
.. montrer quelque chose ..
@@ -148,11 +150,11 @@
.. apaiser quelquechose ..
end</pre>
-<p>Les routes sont évaluées dans lordre où elles ont été définies. La
+<p>Les routes sont évaluées dans l'ordre où elles ont été définies. La
première route qui correspond à la requête est appelée.</p>
<p>Les masques peuvent inclure des paramètres nommés, accessibles par
-lintermédiaire du hash <tt>params</tt> :</p>
+l'intermédiaire du hash <tt>params</tt> :</p>
<pre>get '/bonjour/:nom' do
# répond aux requêtes &quot;GET /bonjour/foo&quot; et &quot;GET /bonjour/bar&quot;
@@ -168,7 +170,7 @@
end</pre>
<p>Une route peut contenir un splat (caractère joker), accessible par
-lintermédiaire du tableau <tt>params[:splat]</tt> :</p>
+l'intermédiaire du tableau <tt>params[:splat]</tt> :</p>
<pre>get '/dire/*/a/*' do
# répond à /dire/bonjour/a/monde
@@ -180,7 +182,7 @@
params[:splat] # =&gt; [&quot;chemin/vers/fichier&quot;, &quot;xml&quot;]
end</pre>
-<p>Ou par lintermédiaire des paramètres du bloc :</p>
+<p>Ou par l'intermédiaire des paramètres du bloc :</p>
<pre>get '/telecharger/*.*' do |chemin, ext|
[chemin, ext] # =&gt; [&quot;path/to/file&quot;, &quot;xml&quot;]
@@ -208,7 +210,7 @@
<h3>Conditions</h3>
<p>Les routes peuvent définir toutes sortes de conditions, comme par exemple
-le user agent :</p>
+le "user agent" :</p>
<pre>get '/foo', :agent =&gt; /Songbird (\d\.\d)[\d\/]*?/ do
&quot;Vous utilisez Songbird version #{params[:agent][0]}&quot;