- absolute_redirects
-
如果被禁用，Sinatra会允许使用相对路径重定向， 但是，Sinatra就不再遵守
RFC 2616标准 (HTTP 1.1), 该标准只允许绝对路径重定向。
如果你的应用运行在一个未恰当设置的反向代理之后，
你需要启用这个选项。注意 url 辅助方法 仍然会生成绝对 URL，除非你传入
false 作为第二参数。
默认禁用。
- add_charsets
-
设定 content_type 辅助方法会 自动加上字符集信息的多媒体类型。
你应该添加而不是覆盖这个选项:
settings.add_charsets << "application/foobar"
- app_file
-
主应用文件，用来检测项目的根路径， views和public文件夹和内联模板。
- bind
-
绑定的IP 地址 (默认: 0.0.0.0)。 仅对于内置的服务器有用。
- default_encoding
-
默认编码 (默认为 "utf-8")。
- dump_errors
-
在log中显示错误。
- environment
-
当前环境，默认是 ENV['RACK_ENV']， 或者 "development" 如果不可用。
- logging
-
使用logger
- lock
-
对每一个请求放置一个锁， 只使用进程并发处理请求。
如果你的应用不是线程安全则需启动。 默认禁用。
- method_override
-
使用 _method 魔法以允许在旧的浏览器中在 表单中使用 put/delete 方法
- port
-
监听的端口号。只对内置服务器有用。
- prefixed_redirects
-
是否添加 request.script_name 到
重定向请求，如果没有设定绝对路径。那样的话 redirect '/foo' 会和
redirect to('/foo')起相同作用。默认禁用。
- public_folder
-
public文件夹的位置。
- reload_templates
-
是否每个请求都重新载入模板。 在development mode和 Ruby 1.8.6
中被企业（用来 消除一个Ruby内存泄漏的bug）。
- root
-
项目的根目录。
- raise_errors
-
抛出异常（应用会停下）。
- run
-
如果启用，Sinatra会开启web服务器。 如果使用rackup或其他方式则不要启用。
- running
-
内置的服务器在运行吗？ 不要修改这个设置！
- server
-
服务器，或用于内置服务器的列表。 默认是 [‘thin’, ‘mongrel’, ‘webrick’],
顺序表明了 优先级。
- sessions
-
开启基于cookie的sesson。
- show_exceptions
-
在浏览器中显示一个stack trace。
- static
-
Sinatra是否处理静态文件。 当服务器能够处理则禁用。 禁用会增强性能。
默认开启。
- views
-
views 文件夹。
## 错误处理
错误处理在与路由和前置过滤器相同的上下文中运行，
这意味着你可以使用许多好东西，比如 `haml`, `erb`, `halt`，等等。
### 未找到
当一个 `Sinatra::NotFound` 错误被抛出的时候，
或者响应状态码是404，`not_found` 处理器会被调用：
~~~~ {.ruby}
not_found do
'This is nowhere to be found'
end
~~~~
### 错误
`error` 处理器，在任何路由代码块或者过滤器抛出异常的时候会被调用。
异常对象可以通过`sinatra.error` Rack 变量获得：
~~~~ {.ruby}
error do
'Sorry there was a nasty error - ' + env['sinatra.error'].name
end
~~~~
自定义错误：
~~~~ {.ruby}
error MyCustomError do
'So what happened was...' + env['sinatra.error'].message
end
~~~~
那么，当这个发生的时候：
~~~~ {.ruby}
get '/' do
raise MyCustomError, 'something bad'
end
~~~~
你会得到：
So what happened was... something bad
另一种替代方法是，为一个状态码安装错误处理器：
~~~~ {.ruby}
error 403 do
'Access forbidden'
end
get '/secret' do
403
end
~~~~
或者一个范围：
~~~~ {.ruby}
error 400..510 do
'Boom'
end
~~~~
在运行在development环境下时，Sinatra会安装特殊的 `not_found` 和 `error`
处理器。
## Rack 中间件
Sinatra 依靠 [Rack](http://rack.rubyforge.org/), 一个面向Ruby
web框架的最小标准接口。
Rack的一个最有趣的面向应用开发者的能力是支持“中间件”——坐落在服务器和你的应用之间，
监视 并/或 操作HTTP请求/响应以 提供多样类型的常用功能。
Sinatra 让建立Rack中间件管道异常简单， 通过顶层的 `use` 方法：
~~~~ {.ruby}
require 'sinatra'
require 'my_custom_middleware'
use Rack::Lint
use MyCustomMiddleware
get '/hello' do
'Hello World'
end
~~~~
`use` 的语义和在
[Rack::Builder](http://rack.rubyforge.org/doc/classes/Rack/Builder.html)
DSL(在rack文件中最频繁使用)中定义的完全一样。例如，`use` 方法接受
多个/可变 参数，包括代码块：
~~~~ {.ruby}
use Rack::Auth::Basic do |username, password|
username == 'admin' && password == 'secret'
end
~~~~
Rack中分布有多样的标准中间件，针对日志，
调试，URL路由，认证和session处理。 Sinatra会自动使用这里面的大部分组件，
所以你一般不需要显示地 `use` 他们。
## 测试
Sinatra的测试可以使用任何基于Rack的测试程序库或者框架来编写。
[Rack::Test](http://gitrdoc.com/brynary/rack-test) 是推荐候选：
~~~~ {.ruby}
require 'my_sinatra_app'
require 'test/unit'
require 'rack/test'
class MyAppTest < Test::Unit::TestCase
include Rack::Test::Methods
def app
Sinatra::Application
end
def test_my_default
get '/'
assert_equal 'Hello World!', last_response.body
end
def test_with_params
get '/meet', :name => 'Frank'
assert_equal 'Hello Frank!', last_response.body
end
def test_with_rack_env
get '/', {}, 'HTTP_USER_AGENT' => 'Songbird'
assert_equal "You're using Songbird!", last_response.body
end
end
~~~~
请注意: 内置的 Sinatra::Test 模块和 Sinatra::TestHarness 类 在 0.9.2
版本已废弃。
## Sinatra::Base - 中间件，程序库和模块化应用
把你的应用定义在顶层，对于微型应用这会工作得很好，
但是在构建可复用的组件时候会带来客观的不利， 比如构建Rack中间件，Rails
metal，带有服务器组件的简单程序库，
或者甚至是Sinatra扩展。顶层的DSL污染了Object命名空间，
并假定了一个微型应用风格的配置 (例如, 单一的应用文件， ./public 和
./views 目录，日志，异常细节页面，等等）。 这时应该让 Sinatra::Base
走到台前了：
~~~~ {.ruby}
require 'sinatra/base'
class MyApp < Sinatra::Base
set :sessions, true
set :foo, 'bar'
get '/' do
'Hello world!'
end
end
~~~~
Sinatra::Base子类可用的方法实际上就是通过顶层 DSL 可用的方法。
大部分顶层应用可以通过两个改变转换成Sinatra::Base组件：
- 你的文件应当引入 `sinatra/base` 而不是 `sinatra`;
否则，所有的Sinatra的 DSL 方法将会被引进到 主命名空间。
- 把你的应用的路由，错误处理，过滤器和选项放在
一个Sinatra::Base的子类中。
`+Sinatra::Base+` 是一张白纸。大部分的选项默认是禁用的，
包含内置的服务器。参见
[选项和配置](http://sinatra.github.com/configuration.html)
查看可用选项的具体细节和他们的行为。
### 模块化 vs. 传统的方式
与通常的认识相反，传统的方式没有任何错误。
如果它适合你的应用，你不需要转换到模块化的应用。
和模块化方式相比只有两个缺点:
- 你对每个Ruby进程只能定义一个Sinatra应用，如果你需要更多，
切换到模块化方式。
- 传统方式使用代理方法污染了 Object 。如果你打算 把你的应用封装进一个
library/gem，转换到模块化方式。
没有任何原因阻止你混合模块化和传统方式。
如果从一种转换到另一种，你需要注意settings中的 一些微小的不同:
Setting Classic Modular
app_file file loading sinatra nil
run $0 == app_file false
logging true false
method_override true false
inline_templates true false
### 运行一个模块化应用
有两种方式运行一个模块化应用，使用 `run!`来运行:
~~~~ {.ruby}
# my_app.rb
require 'sinatra/base'
class MyApp < Sinatra::Base
# ... app code here ...
# start the server if ruby file executed directly
run! if app_file == $0
end
~~~~
运行:
ruby my_app.rb
或者使用一个 `config.ru`，允许你使用任何Rack处理器:
~~~~ {.ruby}
# config.ru
require './my_app'
run MyApp
~~~~
运行:
rackup -p 4567
### 使用config.ru运行传统方式的应用
编写你的应用:
~~~~ {.ruby}
# app.rb
require 'sinatra'
get '/' do
'Hello world!'
end
~~~~
加入相应的 `config.ru`:
~~~~ {.ruby}
require './app'
run Sinatra::Application
~~~~
### 什么时候用 config.ru?
以下情况你可能需要使用 `config.ru`:
- 你要使用不同的 Rack 处理器部署 (Passenger, Unicorn, Heroku, …).
- 你想使用一个或者多个 `Sinatra::Base`的子类.
- 你只想把Sinatra当作中间件使用，而不是端点。
**你并不需要切换到`config.ru`仅仅因为你切换到模块化方式，
你同样不需要切换到模块化方式， 仅仅因为要运行 `config.ru`.**
### 把Sinatra当成中间件来使用
不仅Sinatra有能力使用其他的Rack中间件，任何Sinatra
应用程序都可以反过来自身被当作中间件，被加在任何Rack端点前面。
这个端点可以是任何Sinatra应用，或者任何基于Rack的应用程序
(Rails/Ramaze/Camping/…)。
~~~~ {.ruby}
require 'sinatra/base'
class LoginScreen < Sinatra::Base
enable :sessions
get('/login') { haml :login }
post('/login') do
if params[:name] = 'admin' and params[:password] = 'admin'
session['user_name'] = params[:name]
else
redirect '/login'
end
end
end
class MyApp < Sinatra::Base
# 在前置过滤器前运行中间件
use LoginScreen
before do
unless session['user_name']
halt "Access denied, please