Merge pull request #929 from burningTyger/master
some updates to the German and English Readmes
This commit is contained in:
commit
e7f65ab3de
158
README.de.md
158
README.de.md
|
@ -1,7 +1,7 @@
|
|||
# Sinatra
|
||||
|
||||
*Wichtig: Dieses Dokument ist eine Übersetzung aus dem Englischen und unter
|
||||
Umständen nicht auf dem aktuellen Stand (aktuell Sinatra 1.4.2).*
|
||||
Umständen nicht auf dem aktuellen Stand (aktuell Sinatra 1.4.5).*
|
||||
|
||||
Sinatra ist eine
|
||||
[DSL](http://de.wikipedia.org/wiki/Domänenspezifische_Sprache), die das
|
||||
|
@ -54,11 +54,13 @@ aufgerufen werden.
|
|||
* [Markdown Templates](#markdown-templates)
|
||||
* [Textile Templates](#textile-templates)
|
||||
* [RDoc Templates](#rdoc-templates)
|
||||
* [AsciiDoc Templates](#asciidoc-templates)
|
||||
* [Radius Templates](#radius-templates)
|
||||
* [Markaby Templates](#markaby-templates)
|
||||
* [RABL Templates](#rabl-templates)
|
||||
* [Slim Templates](#slim-templates)
|
||||
* [Creole Templates](#creole-templates)
|
||||
* [MediaWiki Templates](#mediawiki-templates)
|
||||
* [CoffeeScript Templates](#coffeescript-templates)
|
||||
* [Stylus Templates](#stylus-templates)
|
||||
* [Yajl Templates](#yajl-templates)
|
||||
|
@ -69,6 +71,7 @@ aufgerufen werden.
|
|||
* [Benannte Templates](#benannte-templates)
|
||||
* [Dateiendungen zuordnen](#dateiendungen-zuordnen)
|
||||
* [Eine eigene Template-Engine hinzufügen](#eine-eigene-template-engine-hinzufgen)
|
||||
* [Eigene Methoden zum Aufsuchen von Templates verwenden](#eigene-methoden-zum-aufsuchen-von-templates-verwenden)
|
||||
* [Filter](#filter)
|
||||
* [Helfer](#helfer)
|
||||
* [Sessions verwenden](#sessions-verwenden)
|
||||
|
@ -222,6 +225,17 @@ get '/posts.?:format?' do
|
|||
end
|
||||
```
|
||||
|
||||
Routen können auch den query-Parameter verwenden:
|
||||
|
||||
``` ruby
|
||||
get '/posts' do
|
||||
# matches "GET /posts?title=foo&author=bar"
|
||||
title = params['title']
|
||||
author = params['author']
|
||||
# uses title and author variables; query is optional to the /posts route
|
||||
end
|
||||
```
|
||||
|
||||
Anmerkung: Solange man den sog. Path Traversal Attack-Schutz nicht deaktiviert
|
||||
(siehe weiter unten), kann es sein, dass der Request-Pfad noch vor dem
|
||||
Abgleich mit den Routen modifiziert wird.
|
||||
|
@ -261,6 +275,7 @@ get '/', :provides => ['rss', 'atom', 'xml'] do
|
|||
builder :feed
|
||||
end
|
||||
```
|
||||
`provides` durchsucht den Accept-Header der Anfrage
|
||||
|
||||
Eigene Bedingungen können relativ einfach hinzugefügt werden:
|
||||
|
||||
|
@ -801,6 +816,27 @@ 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
|
||||
`:layout_engine`-Option verwendet wird.
|
||||
|
||||
#### AsciiDoc Templates
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td>Abhängigkeit</td>
|
||||
<td><a href="http://asciidoctor.org/" title="Asciidoctor">Asciidoctor</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Dateierweiterungen</td>
|
||||
<td><tt>.asciidoc</tt>, <tt>.adoc</tt> und <tt>.ad</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Beispiel</td>
|
||||
<td><tt>asciidoc :README, :layout_engine => :erb</tt></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Da man aus dem AsciiDoc-Template heraus keine Ruby-Methoden aufrufen kann
|
||||
(ausgenommen `yield`), wird man üblicherweise locals verwenden wollen, mit
|
||||
denen man Variablen weitergibt.
|
||||
|
||||
#### Radius Templates
|
||||
|
||||
<table>
|
||||
|
@ -912,6 +948,44 @@ Creole geschrieben werden. Es ist aber möglich, einen Renderer für die Templat
|
|||
zu verwenden und einen anderen für das Layout, indem die `:layout_engine`-Option
|
||||
verwendet wird.
|
||||
|
||||
#### MediaWiki Templates
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td>Abhängigkeit</td>
|
||||
<td><a href="https://github.com/nricciar/wikicloth" title="WikiCloth">WikiCloth</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Dateierweiterungen</td>
|
||||
<td><tt>.mediawiki</tt> und <tt>.mw</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Beispiel</td>
|
||||
<td><tt>mediawiki :wiki, :layout_engine => :erb</tt></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Da man aus dem Mediawiki-Template heraus keine Ruby-Methoden aufrufen und auch
|
||||
keine locals verwenden kann, wird man Mediawiki üblicherweise in Kombination mit
|
||||
anderen Renderern verwenden wollen:
|
||||
|
||||
``` ruby
|
||||
erb :overview, :locals => { :text => mediawiki(:introduction) }
|
||||
```
|
||||
|
||||
Beachte: Man kann die `mediawiki`-Methode auch aus anderen Templates
|
||||
heraus aufrufen:
|
||||
|
||||
``` ruby
|
||||
%h1 Grüße von Haml!
|
||||
%p= mediawiki(:greetings)
|
||||
```
|
||||
|
||||
Da man Ruby nicht von MediaWiki heraus aufrufen kann, können auch Layouts nicht
|
||||
in MediaWiki geschrieben werden. Es ist aber möglich, einen Renderer für die
|
||||
Templates zu verwenden und einen anderen für das Layout, indem die
|
||||
`:layout_engine`-Option verwendet wird.
|
||||
|
||||
#### CoffeeScript Templates
|
||||
|
||||
<table>
|
||||
|
@ -1002,8 +1076,9 @@ json[:baz] = key
|
|||
Die `:callback` und `:variable` Optionen können mit dem gerenderten Objekt
|
||||
verwendet werden:
|
||||
|
||||
``` ruby
|
||||
var resource = {"foo":"bar","baz":"qux"}; present(resource);
|
||||
``` javascript
|
||||
var resource = {"foo":"bar","baz":"qux"};
|
||||
present(resource);
|
||||
```
|
||||
|
||||
#### WLang Templates
|
||||
|
@ -1023,9 +1098,9 @@ var resource = {"foo":"bar","baz":"qux"}; present(resource);
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
Ruby-Methoden in wlang aufzurufen entspricht nicht den idiomatischen Vorgaben
|
||||
von wlang, es bietet sich deshalb an, `:locals` zu verwenden. Layouts, die
|
||||
wlang und `yield` verwenden, werden aber trotzdem unterstützt.
|
||||
Ruby-Methoden in Wlang aufzurufen entspricht nicht den idiomatischen Vorgaben
|
||||
von Wlang, es bietet sich deshalb an, `:locals` zu verwenden. Layouts, die
|
||||
Wlang und `yield` verwenden, werden aber trotzdem unterstützt.
|
||||
|
||||
Rendert den eingebetteten Template-String.
|
||||
|
||||
|
@ -1177,6 +1252,23 @@ Dieser Code rendert `./views/application.mtt`. Siehe
|
|||
[github.com/rtomayko/tilt](https://github.com/rtomayko/tilt), um mehr über
|
||||
Tilt zu erfahren.
|
||||
|
||||
### Eigene Methoden zum Aufsuchen von Templates verwenden
|
||||
|
||||
Um einen eigenen Mechanismus zum Aufsuchen von Templates zu
|
||||
implementieren, muss `#find_template` definiert werden:
|
||||
|
||||
``` ruby
|
||||
configure do
|
||||
set :views [ './views/a', './views/b' ]
|
||||
end
|
||||
|
||||
def find_template(views, name, engine, &block)
|
||||
Array(views).each do |v|
|
||||
super(v, name, engine, &block)
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
## Filter
|
||||
|
||||
Before-Filter werden vor jedem Request in demselben Kontext, wie danach die
|
||||
|
@ -1300,6 +1392,13 @@ Einstellungen ablegen.
|
|||
set :sessions, :domain => 'foo.com'
|
||||
```
|
||||
|
||||
Um eine Session mit anderen Apps und zwischen verschiedenen Subdomains
|
||||
von foo.com zu teilen, wird ein *.* der Domain vorangestellt:
|
||||
|
||||
``` ruby
|
||||
set :sessions, :domain => '.foo,com'
|
||||
```
|
||||
|
||||
### Anhalten
|
||||
|
||||
Zum sofortigen Stoppen eines Request in einem Filter oder einer Route:
|
||||
|
@ -1476,7 +1575,7 @@ get '/subscribe' do
|
|||
"Angemeldet"
|
||||
end
|
||||
|
||||
post '/message' do
|
||||
post '/:message' do
|
||||
connections.each do |out|
|
||||
# Den Client über eine neue Nachricht in Kenntnis setzen
|
||||
# notify client that a new message has arrived
|
||||
|
@ -1711,7 +1810,8 @@ etag '', :new_resource => true, :kind => :weak
|
|||
|
||||
### Dateien versenden
|
||||
|
||||
Zum Versenden von Dateien kann die `send_file`-Helfer-Methode verwendet werden:
|
||||
Um den Inhalt einer Datei als Response zurückzugeben, kann die
|
||||
`send_file`-Helfer-Methode verwendet werden:
|
||||
|
||||
```ruby
|
||||
get '/' do
|
||||
|
@ -2125,6 +2225,9 @@ set :protection, :except => [:path_traversal, :session_hijacking]
|
|||
<dd>Wird es auf <tt>true</tt> gesetzt, wird Thin aufgefordert
|
||||
<tt>EventMachine.defer</tt> zur Verarbeitung des Requests einzusetzen.</dd>
|
||||
|
||||
<dt>traps</dt>
|
||||
<dd>Einstellung, Sinatra System signalen umgehen soll.</dd>
|
||||
|
||||
<dt>views</dt>
|
||||
<dd>Verzeichnis der Views. Leitet sich von der <tt>app_file</tt> Einstellung
|
||||
ab, wenn nicht gesetzt.</dd>
|
||||
|
@ -2172,8 +2275,15 @@ end
|
|||
### Fehler
|
||||
|
||||
Der `error`-Handler wird immer ausgeführt, wenn eine Exception in einem
|
||||
Routen-Block oder in einem Filter geworfen wurde. Die Exception kann über die
|
||||
`sinatra.error`-Rack-Variable angesprochen werden:
|
||||
Routen-Block oder in einem Filter geworfen wurde. In der
|
||||
`development`-Umgebung wird es nur dann funktionieren, wenn die
|
||||
`:show_exceptions`-Option auf `:after_handler` eingestellt wurde:
|
||||
|
||||
```ruby
|
||||
set :show_exceptions, :after_handler
|
||||
```
|
||||
|
||||
Die Exception kann über die `sinatra.error`-Rack-Variable angesprochen werden:
|
||||
|
||||
```ruby
|
||||
error do
|
||||
|
@ -2353,12 +2463,24 @@ Veränderungen zu `Sinatra::Base` konvertiert werden:
|
|||
* Alle Routen, Error-Handler, Filter und Optionen der Applikation müssen in
|
||||
einer Subklasse von `Sinatra::Base` definiert werden.
|
||||
|
||||
|
||||
`Sinatra::Base` ist ein unbeschriebenes Blatt. Die meisten Optionen sind per
|
||||
Standard deaktiviert. Das betrifft auch den eingebauten Server. Siehe
|
||||
[Optionen und Konfiguration](http://sinatra.github.com/configuration.html) für
|
||||
Details über mögliche Optionen.
|
||||
|
||||
Damit eine App sich ähnlich wie eine klassische App verhält, kann man
|
||||
auch eine Subclass von `Sinatra::Application` erstellen:
|
||||
|
||||
``` ruby
|
||||
require 'sinatra/base'
|
||||
|
||||
class MyApp < Sinatra::Application
|
||||
get '/' do
|
||||
'Hello world!'
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
### Modularer vs. klassischer Stil
|
||||
|
||||
Entgegen häufiger Meinungen gibt es nichts gegen den klassischen Stil
|
||||
|
@ -2379,42 +2501,49 @@ werden:
|
|||
<th>Szenario</th>
|
||||
<th>Classic</th>
|
||||
<th>Modular</th>
|
||||
<th>Modular</th>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>app_file</td>
|
||||
<td>Sinatra ladende Datei</td>
|
||||
<td>Sinatra::Base subklassierende Datei</td>
|
||||
<td>Sinatra::Application subklassierende Datei</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>run</td>
|
||||
<td>$0 == app_file</td>
|
||||
<td>false</td>
|
||||
<td>false</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>logging</td>
|
||||
<td>true</td>
|
||||
<td>false</td>
|
||||
<td>true</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>method_override</td>
|
||||
<td>true</td>
|
||||
<td>false</td>
|
||||
<td>true</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>inline_templates</td>
|
||||
<td>true</td>
|
||||
<td>false</td>
|
||||
<td>true</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>static</td>
|
||||
<td>true</td>
|
||||
<td>false</td>
|
||||
<td>true</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
@ -2714,6 +2843,9 @@ auftreten.</dd>
|
|||
Upgrade von einer früheren Version von Ruby zu Ruby 1.9.3 werden alle Sessions
|
||||
ungültig. Ruby 1.9.3 wird bis Sinatra 2.0 unterstützt werden.</dd>
|
||||
|
||||
<dt>Ruby 2.x</dt>
|
||||
<dd>2.x wird vollständig unterstützt.</dd>
|
||||
|
||||
<dt>Rubinius</dt>
|
||||
<dd>Rubinius (Version >= 2.x) wird offiziell unterstützt. Es wird empfohlen, den
|
||||
<a href="http://puma.io">Puma Server</a> zu installieren (<tt>gem install puma
|
||||
|
@ -2738,8 +2870,8 @@ wir davon ausgehen, dass es nicht an Sinatra sondern an der jeweiligen
|
|||
Implementierung liegt.
|
||||
|
||||
Im Rahmen unserer CI (Kontinuierlichen Integration) wird bereits ruby-head
|
||||
(das kommende Ruby 2.1.0) mit eingebunden. Es kann davon ausgegangen
|
||||
werden, dass Sinatra Ruby 2.1.0 vollständig unterstützen wird.
|
||||
(zukünftige Versionen von MRI) mit eingebunden. Es kann davon ausgegangen
|
||||
werden, dass Sinatra MRI auch weiterhin vollständig unterstützen wird.
|
||||
|
||||
Sinatra sollte auf jedem Betriebssystem laufen, dass einen funktionierenden
|
||||
Ruby-Interpreter aufweist.
|
||||
|
|
152
README.md
152
README.md
|
@ -480,8 +480,9 @@ Available Options:
|
|||
|
||||
<dt>layout</dt>
|
||||
<dd>
|
||||
Whether to use a layout (<tt>true</tt> or <tt>false</tt>). If it's a Symbol, specifies
|
||||
what template to use. Example: <tt>erb :index, :layout => !request.xhr?</tt>
|
||||
Whether to use a layout (<tt>true</tt> or <tt>false</tt>). If it's a
|
||||
Symbol, specifies what template to use. Example:
|
||||
<tt>erb :index, :layout => !request.xhr?</tt>
|
||||
</dd>
|
||||
|
||||
<dt>content_type</dt>
|
||||
|
@ -821,8 +822,8 @@ template than for the layout by passing the `:layout_engine` option.
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
Since you cannot call Ruby methods directly from an AsciiDoc template, you almost
|
||||
always want to pass locals to it.
|
||||
Since you cannot call Ruby methods directly from an AsciiDoc template, you
|
||||
almost always want to pass locals to it.
|
||||
|
||||
#### Radius Templates
|
||||
|
||||
|
@ -949,8 +950,9 @@ template than for the layout by passing the `:layout_engine` option.
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
It is not possible to call methods from MediaWiki markup, nor to pass locals to it.
|
||||
You therefore will usually use it in combination with another rendering engine:
|
||||
It is not possible to call methods from MediaWiki markup, nor to pass locals to
|
||||
it. You therefore will usually use it in combination with another rendering
|
||||
engine:
|
||||
|
||||
``` ruby
|
||||
erb :overview, :locals => { :text => mediawiki(:introduction) }
|
||||
|
@ -1086,8 +1088,8 @@ present(resource);
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
Since calling ruby methods is not idiomatic in WLang, you almost always want to pass locals
|
||||
to it. Layouts written in WLang and `yield` are supported, though.
|
||||
Since calling ruby methods is not idiomatic in WLang, you almost always want to
|
||||
pass locals to it. Layouts written in WLang and `yield` are supported, though.
|
||||
|
||||
### Accessing Variables in Templates
|
||||
|
||||
|
@ -1127,8 +1129,7 @@ end
|
|||
|
||||
This code is mostly equivalent to `erb :index, :layout => :post`.
|
||||
|
||||
Passing blocks to rendering methods is most useful for creating nested
|
||||
layouts:
|
||||
Passing blocks to rendering methods is most useful for creating nested layouts:
|
||||
|
||||
``` ruby
|
||||
erb :main_layout, :layout => false do
|
||||
|
@ -1147,8 +1148,7 @@ end
|
|||
```
|
||||
|
||||
Currently, the following rendering methods accept a block: `erb`, `haml`,
|
||||
`liquid`, `slim `, `wlang`.
|
||||
Also the general `render` method accepts a block.
|
||||
`liquid`, `slim `, `wlang`. Also the general `render` method accepts a block.
|
||||
|
||||
### Inline Templates
|
||||
|
||||
|
@ -1268,9 +1268,9 @@ get '/foo/*' do
|
|||
end
|
||||
```
|
||||
|
||||
After filters are evaluated after each request within the same
|
||||
context as the routes will be and can also modify the request and response. Instance
|
||||
variables set in before filters and routes are accessible by after filters:
|
||||
After filters are evaluated after each request within the same context as the
|
||||
routes will be and can also modify the request and response. Instance variables
|
||||
set in before filters and routes are accessible by after filters:
|
||||
|
||||
``` ruby
|
||||
after do
|
||||
|
@ -1471,8 +1471,7 @@ end
|
|||
```
|
||||
|
||||
Note that in the example above, you would ease testing and increase performance
|
||||
by simply moving `"bar"` into a helper used by both `/foo`
|
||||
and `/bar`.
|
||||
by simply moving `"bar"` into a helper used by both `/foo` and `/bar`.
|
||||
|
||||
If you want the request to be sent to the same application instance rather than
|
||||
a duplicate, use `call!` instead of `call`.
|
||||
|
@ -1597,9 +1596,8 @@ This logger will automatically take your Rack handler's logging settings into
|
|||
account. If logging is disabled, this method will return a dummy object, so
|
||||
you do not have to worry about it in your routes and filters.
|
||||
|
||||
Note that logging is only enabled for `Sinatra::Application` by
|
||||
default, so if you inherit from `Sinatra::Base`, you probably want to
|
||||
enable it yourself:
|
||||
Note that logging is only enabled for `Sinatra::Application` by default, so if
|
||||
you inherit from `Sinatra::Base`, you probably want to enable it yourself:
|
||||
|
||||
``` ruby
|
||||
class MyApp < Sinatra::Base
|
||||
|
@ -1730,8 +1728,8 @@ end
|
|||
```
|
||||
|
||||
To properly use caches, you should consider using `etag` or `last_modified`.
|
||||
It is recommended to call those helpers *before* doing any heavy lifting, as they
|
||||
will immediately flush a response if the client already has the current
|
||||
It is recommended to call those helpers *before* doing any heavy lifting, as
|
||||
they will immediately flush a response if the client already has the current
|
||||
version in its cache:
|
||||
|
||||
``` ruby
|
||||
|
@ -1793,7 +1791,8 @@ etag '', :new_resource => true, :kind => :weak
|
|||
|
||||
### Sending Files
|
||||
|
||||
To return the contents of a file as the response, you can use the `send_file` helper method:
|
||||
To return the contents of a file as the response, you can use the `send_file`
|
||||
helper method:
|
||||
|
||||
``` ruby
|
||||
get '/' do
|
||||
|
@ -1817,12 +1816,13 @@ The options are:
|
|||
<dd>Value for Last-Modified header, defaults to the file's mtime.</dd>
|
||||
|
||||
<dt>type</dt>
|
||||
<dd>Value for Content-Type header, guessed from the file extension if missing.</dd>
|
||||
<dd>Value for Content-Type header, guessed from the file extension if
|
||||
missing.</dd>
|
||||
|
||||
<dt>disposition</dt>
|
||||
<dd>
|
||||
Value for Content-Disposition header, possible values: <tt>nil</tt> (default),
|
||||
<tt>:attachment</tt> and <tt>:inline</tt>
|
||||
Value for Content-Disposition header, possible values: <tt>nil</tt>
|
||||
(default), <tt>:attachment</tt> and <tt>:inline</tt>
|
||||
</dd>
|
||||
|
||||
<dt>length</dt>
|
||||
|
@ -1833,8 +1833,8 @@ The options are:
|
|||
Status code to be sent. Useful when sending a static file as an error page.
|
||||
|
||||
If supported by the Rack handler, other means than streaming from the Ruby
|
||||
process will be used. If you use this helper method, Sinatra will automatically
|
||||
handle range requests.
|
||||
process will be used. If you use this helper method, Sinatra will
|
||||
automatically handle range requests.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
@ -1876,8 +1876,7 @@ get '/foo' do
|
|||
end
|
||||
```
|
||||
|
||||
Some options, like `script_name` or `path_info`, can also be
|
||||
written:
|
||||
Some options, like `script_name` or `path_info`, can also be written:
|
||||
|
||||
``` ruby
|
||||
before { request.path_info = "/" }
|
||||
|
@ -1920,9 +1919,8 @@ end
|
|||
|
||||
### Dealing with Date and Time
|
||||
|
||||
Sinatra offers a `time_for` helper method that generates a Time object
|
||||
from the given value. It is also able to convert `DateTime`, `Date` and
|
||||
similar classes:
|
||||
Sinatra offers a `time_for` helper method that generates a Time objectfrom the
|
||||
given value. It is also able to convert `DateTime`, `Date` and similar classes:
|
||||
|
||||
``` ruby
|
||||
get '/' do
|
||||
|
@ -2116,7 +2114,9 @@ set :protection, :session => true
|
|||
</dd>
|
||||
|
||||
<dt>bind</dt>
|
||||
<dd>IP address to bind to (default: <tt>0.0.0.0</tt> <em>or</em> <tt>localhost</tt> if your `environment` is set to development.). Only used for built-in server.</dd>
|
||||
<dd>IP address to bind to (default: <tt>0.0.0.0</tt> <em>or</em>
|
||||
<tt>localhost</tt> if your `environment` is set to development). Only used
|
||||
for built-in server.</dd>
|
||||
|
||||
<dt>default_encoding</dt>
|
||||
<dd>Encoding to assume if unknown (defaults to <tt>"utf-8"</tt>).</dd>
|
||||
|
@ -2126,8 +2126,8 @@ set :protection, :session => true
|
|||
|
||||
<dt>environment</dt>
|
||||
<dd>
|
||||
Current environment. Defaults to <tt>ENV['RACK_ENV']</tt>, or <tt>"development"</tt> if
|
||||
not available.
|
||||
Current environment. Defaults to <tt>ENV['RACK_ENV']</tt>, or
|
||||
<tt>"development"</tt> if not available.
|
||||
</dd>
|
||||
|
||||
<dt>logging</dt>
|
||||
|
@ -2157,7 +2157,8 @@ set :protection, :session => true
|
|||
</dd>
|
||||
|
||||
<dt>protection</dt>
|
||||
<dd>Whether or not to enable web attack protections. See protection section above.</dd>
|
||||
<dd>Whether or not to enable web attack protections. See protection section
|
||||
above.</dd>
|
||||
|
||||
<dt>public_dir</dt>
|
||||
<dd>Alias for <tt>public_folder</tt>. See below.</dd>
|
||||
|
@ -2171,12 +2172,14 @@ set :protection, :session => true
|
|||
|
||||
<dt>reload_templates</dt>
|
||||
<dd>
|
||||
Whether or not to reload templates between requests. Enabled in development mode.
|
||||
Whether or not to reload templates between requests. Enabled in development
|
||||
mode.
|
||||
</dd>
|
||||
|
||||
<dt>root</dt>
|
||||
<dd>
|
||||
Path to project root folder. Inferred from <tt>app_file</tt> setting if not set.
|
||||
Path to project root folder. Inferred from <tt>app_file</tt> setting if not
|
||||
set.
|
||||
</dd>
|
||||
|
||||
<dt>raise_errors</dt>
|
||||
|
@ -2208,14 +2211,13 @@ set :protection, :session => true
|
|||
|
||||
<dt>show_exceptions</dt>
|
||||
<dd>
|
||||
Show a stack trace in the browser when an exception
|
||||
happens. Enabled by default when <tt>environment</tt>
|
||||
is set to <tt>"development"</tt>, disabled otherwise.
|
||||
Show a stack trace in the browser when an exception happens. Enabled by
|
||||
default when <tt>environment</tt> is set to <tt>"development"</tt>,
|
||||
disabled otherwise.
|
||||
</dd>
|
||||
<dd>
|
||||
Can also be set to <tt>:after_handler</tt> to trigger
|
||||
app-specified error handling before showing a stack
|
||||
trace in the browser.
|
||||
Can also be set to <tt>:after_handler</tt> to trigger app-specified error
|
||||
handling before showing a stack trace in the browser.
|
||||
</dd>
|
||||
|
||||
<dt>static</dt>
|
||||
|
@ -2223,15 +2225,14 @@ set :protection, :session => true
|
|||
<dd>Disable when using a server able to do this on its own.</dd>
|
||||
<dd>Disabling will boost performance.</dd>
|
||||
<dd>
|
||||
Enabled per default in classic style, disabled for
|
||||
modular apps.
|
||||
Enabled per default in classic style, disabled for modular apps.
|
||||
</dd>
|
||||
|
||||
<dt>static_cache_control</dt>
|
||||
<dd>
|
||||
When Sinatra is serving static files, set this to add
|
||||
<tt>Cache-Control</tt> headers to the responses. Uses the
|
||||
<tt>cache_control</tt> helper. Disabled by default.
|
||||
When Sinatra is serving static files, set this to add <tt>Cache-Control</tt>
|
||||
headers to the responses. Uses the <tt>cache_control</tt> helper. Disabled
|
||||
by default.
|
||||
</dd>
|
||||
<dd>
|
||||
Use an explicit array when setting multiple values:
|
||||
|
@ -2262,13 +2263,12 @@ set :protection, :session => true
|
|||
|
||||
## Environments
|
||||
|
||||
There are three predefined `environments`: `"development"`,
|
||||
`"production"` and `"test"`. Environments can be set
|
||||
through the `RACK_ENV` environment variable. The default value is
|
||||
`"development"`. In the `"development"` environment all templates are reloaded between
|
||||
requests, and special `not_found` and `error` handlers
|
||||
display stack traces in your browser.
|
||||
In the `"production"` and `"test"` environments, templates are cached by default.
|
||||
There are three predefined `environments`: `"development"`, `"production"` and
|
||||
`"test"`. Environments can be set through the `RACK_ENV` environment variable.
|
||||
The default value is `"development"`. In the `"development"` environment all
|
||||
templates are reloaded between requests, and special `not_found` and `error`
|
||||
handlers display stack traces in your browser. In the `"production"` and
|
||||
`"test"` environments, templates are cached by default.
|
||||
|
||||
To run different environments, set the `RACK_ENV` environment variable:
|
||||
|
||||
|
@ -2310,13 +2310,13 @@ end
|
|||
|
||||
The `error` handler is invoked any time an exception is raised from a route
|
||||
block or a filter. But note in development it will only run if you set the
|
||||
show exceptions option to `:after_handler`.
|
||||
show exceptions option to `:after_handler`:
|
||||
|
||||
```ruby
|
||||
set :show_exceptions, :after_handler
|
||||
```
|
||||
|
||||
The exception object can be obtained from the `sinatra.error` Rack variable.
|
||||
The exception object can be obtained from the `sinatra.error` Rack variable:
|
||||
|
||||
``` ruby
|
||||
error do
|
||||
|
@ -2449,8 +2449,8 @@ class MyAppTest < Test::Unit::TestCase
|
|||
end
|
||||
```
|
||||
|
||||
Note: If you are using Sinatra in the modular style, replace `Sinatra::Application`
|
||||
above with the class name of your app.
|
||||
Note: If you are using Sinatra in the modular style, replace
|
||||
`Sinatra::Application` above with the class name of your app.
|
||||
|
||||
## Sinatra::Base - Middleware, Libraries, and Modular Apps
|
||||
|
||||
|
@ -2475,8 +2475,8 @@ class MyApp < Sinatra::Base
|
|||
end
|
||||
```
|
||||
|
||||
The methods available to `Sinatra::Base` subclasses are exactly the same as those
|
||||
available via the top-level DSL. Most top-level apps can be converted to
|
||||
The methods available to `Sinatra::Base` subclasses are exactly the same as
|
||||
those available via the top-level DSL. Most top-level apps can be converted to
|
||||
`Sinatra::Base` components with two modifications:
|
||||
|
||||
* Your file should require `sinatra/base` instead of `sinatra`;
|
||||
|
@ -2490,7 +2490,7 @@ including the built-in server. See
|
|||
[Configuring Settings](http://sinatra.github.com/configuration.html)
|
||||
for details on available options and their behavior. If you want
|
||||
behavior more similar to when you define your app at the top level (also
|
||||
know as Classic style), you
|
||||
known as Classic style), you
|
||||
can subclass `Sinatra::Application`.
|
||||
|
||||
``` ruby
|
||||
|
@ -2508,10 +2508,10 @@ end
|
|||
Contrary to common belief, there is nothing wrong with the classic style. If it
|
||||
suits your application, you do not have to switch to a modular application.
|
||||
|
||||
The main disadvantage of using the classic style rather than the modular style is that
|
||||
you will only have one Sinatra application per Ruby process. If you plan to use
|
||||
more than one, switch to the modular style. There is no reason you cannot mix
|
||||
the modular and the classic styles.
|
||||
The main disadvantage of using the classic style rather than the modular style
|
||||
is that you will only have one Sinatra application per Ruby process. If you
|
||||
plan to use more than one, switch to the modular style. There is no reason you
|
||||
cannot mix the modular and the classic styles.
|
||||
|
||||
If switching from one style to the other, you should be aware of slightly
|
||||
different default settings:
|
||||
|
@ -2633,9 +2633,9 @@ A `config.ru` file is recommended if:
|
|||
* You want to use more than one subclass of `Sinatra::Base`.
|
||||
* You want to use Sinatra only for middleware, and not as an endpoint.
|
||||
|
||||
**There is no need to switch to a `config.ru` simply because you
|
||||
switched to the modular style, and you don't have to use the modular style for running
|
||||
with a `config.ru`.**
|
||||
**There is no need to switch to a `config.ru` simply because you switched to
|
||||
the modular style, and you don't have to use the modular style for running with
|
||||
a `config.ru`.**
|
||||
|
||||
### Using Sinatra as Middleware
|
||||
|
||||
|
@ -2856,9 +2856,9 @@ The following Ruby versions are officially supported:
|
|||
until the release of Sinatra 2.0.
|
||||
</dd>
|
||||
|
||||
<dt>Ruby 2.0.0</dt>
|
||||
<dt>Ruby 2.x</dt>
|
||||
<dd>
|
||||
2.0.0 is fully supported and recommended. There are currently no plans to drop
|
||||
2.x is fully supported and recommended. There are currently no plans to drop
|
||||
official support for it.
|
||||
</dd>
|
||||
|
||||
|
@ -2889,9 +2889,9 @@ known to run Sinatra:
|
|||
Not being officially supported means if things only break there and not on a
|
||||
supported platform, we assume it's not our issue but theirs.
|
||||
|
||||
We also run our CI against ruby-head (the upcoming 2.1.0), but we can't
|
||||
guarantee anything, since it is constantly moving. Expect 2.1.0 to be fully
|
||||
supported.
|
||||
We also run our CI against ruby-head (future releases of MRI), but we can't
|
||||
guarantee anything, since it is constantly moving. Expect upcoming 2.x releases
|
||||
to be fully supported.
|
||||
|
||||
Sinatra should work on any operating system supported by the chosen Ruby
|
||||
implementation.
|
||||
|
|
Loading…
Reference in New Issue