sinatra分析

中关村村草

sinatra分析

备注: 本文是基于sinatra1.0版本，在线文档: sinatra 分析



1.sinatra简介
Sinatra is a DSL for quickly creating web applications in Ruby with minimal。
Fewer classes, less inheritance
controller object mapping & routes vs. URLs---Dont's fear the URLs
Exposed Simplicity instead of hidden complexity
Small things, loosely joined, written fast

2.sinatra分析
2.1.Rack机制
sinatra作为一个web框架，是基于rack规范的。rack规范和Java的servlet规范有点类似，Rack中间件和filter机制有些类似，都是能够拦截 request/response做一些事情。所谓的rack兼容的中间件无非是一个可以执行 call(env) 的对象，详细关于rack的内容可以参考rack官网，还有这个rack 入门文档也很好。
在源码中可以看到，sinatra的Request和Response都是基于rack扩展的，并对 Rack::Request和Rack::Response分别做了一些调整。

sinatra是通过Application.run!来启动服务器的

Ruby代码

1. 
   
2.      def run!(options={})
   
3.         set options
   
4.         handler      = detect_rack_handler
   
5.         handler_name = handler.name.gsub(/.*::/, '')
   
6.         puts "== Sinatra/#{Sinatra::VERSION} has taken the stage " +
   
7.           "on #{port} for #{environment} with backup from #{handler_name}" unless handler_name =~/cgi/i
   
8.         handler.run self, :Host => bind, :Port => port do |server|
   
9.           trap(:INT) do
   
10.             ## Use thins' hard #stop! if available, otherwise just #stop
    
11.             server.respond_to?(:stop!) ? server.stop! : server.stop
    
12.             puts "\n== Sinatra has ended his set (crowd applauds)" unless handler_name =~/cgi/i
    
13.           end
    
14.           set :running, true
    
15.         end
    
16.       rescue Errno::EADDRINUSE => e
    
17.         puts "== Someone is already performing on port #{port}!"
    
18.       end  

复制代码

其中detect_rack_handler是通过 Rack::Handler.get来检测rack处理器的，默认的server有thin/mongrel/webrick,绑定的地址是 0.0.0.0，端口是4567

Ruby代码

1. module Sinatra
   
2.     class Base
   
3.         set :server, %w[thin mongrel webrick]
   
4.         set :bind, '0.0.0.0'
   
5.         set :port, 4567
   
6.     end
   
7. end

复制代码

注意到handler.run self, : Host => bind, : Port => port do |server|,这个self指的是Sinatra :: Base，根据rack规范，最终的请求的入口就是 Sinatra :: Base.call(env)方法

Ruby代码

1.   def prototype
   
2.         @prototype ||= new
   
3.       end
   
4. 
   
5.       # Create a new instance of the class fronted by its middleware
   
6.       # pipeline. The object is guaranteed to respond to #call but may not be
   
7.       # an instance of the class new was called on.
   
8.       def new(*args, &bk)
   
9.         builder = Rack::Builder.new
   
10.         builder.use Rack::Session::Cookie if sessions?
    
11.         builder.use Rack::CommonLogger    if logging?
    
12.         builder.use Rack::MethodOverride  if method_override?
    
13.         builder.use ShowExceptions        if show_exceptions?
    
14.         middleware.each { |c,a,b| builder.use(c, *a, &b) }
    
15. 
    
16.         builder.run super
    
17.         builder.to_app
    
18.       end
    
19. 
    
20.       def call(env)
    
21.         synchronize { prototype.call(env) }
    
22.       end  

复制代码

从 call方法可以看到，是通过生成一个Sinatra::Base实例对象来运行的，最终会调用的是call(env) -> call!(env)

，接下去的工作就是等客户端发送请求过来就可以了。在生成这个实例对象@prototype的时候,直接引入 rack中间件机制，同样，sinatra允许你使用use方法来增加新的中间件(use只是把中间件加入@middleware变量中去而已)。这样 sinatra就已经启动起来了。

2.2.路由机制
sinatra的路由机制和 rails不大一样，sinatra是在controller里边用get/post path这样来指定的。而rails是把controller和map分开处理，通过map来找到对应的controller和action。rails 当初这么搞主要是为了兼容controller和路由不匹配的情况,个人觉得sinatra的写法是非常直观的，也非常的灵活。

Ruby代码

1. delegate :get, :put, :post, :delete, :head, :template, :layout,
   
2.              :before, :after, :error, :not_found, : configure, :set, :mime_type,
   
3.              :enable, :disable, :use, :development?, :test?, :production?,
   
4.              :helpers, :settings

复制代码

看main.rb可以看到include Sinatra:: Delegator，可以把get/post等众多方法代理给Sinatra::Application去执行，在后面使用get '/' do xxx end的时候其实会调用Sinatra::Application(即Sinatra::Base )的get方法。

Ruby代码

1. require 'rubygems'
   
2.   require 'sinatra'
   
3.   get '/' do
   
4.     'Hello world!'
   
5.   end  

复制代码

例如这样一个简单的web应用就可以响应'/'的请求路径，那么Sinatra::Base是怎么识别到这个路由的呢?我们继续来看看上面的get方法做了什么事情，可以看到最终是调用route方法的(同时，从代码可以看到sinatra支持get/post/put/post/delete/head几种method的请求)。按照我们的大概思路，在看到某个请求方法的时候，sinatra会把{请求类型_路径 => 代码块}放到一个专门放路由的地方上去，然后在每一次请求调用call(env)的时候，根据“请求类型_路径”来获得需要执行的代码块。好，继续看看 route的代码是怎么实现的?

Ruby代码

1.    def route(verb, path, options={}, &block)
   
2.         # Because of self.options.host
   
3.         host_name(options.delete(:bind)) if options.key?(:host)
   
4.         options.each {|option, args| send(option, *args)}
   
5. 
   
6.         pattern, keys = compile(path)
   
7.         conditions, @conditions = @conditions, []
   
8. 
   
9.        define_method "#{verb} #{path}", &block
   
10.         unbound_method = instance_method("#{verb} #{path}")
    
11.         block =
    
12.           if block.arity != 0
    
13.             proc { unbound_method.bind(self).call(*@block_params) }
    
14.           else
    
15.             proc { unbound_method.bind(self).call }
    
16.           end
    
17. 
    
18.         invoke_hook(:route_added, verb, path, block)
    
19. 
    
20.         (@routes[verb] ||= []).
    
21.           push([pattern, keys, conditions, block]).last
    
22.       end  

复制代码

这个代码处理的事情比较多，我们来仔细分析分析，前面两句代码是用来记录能够处理的请求的约束(例如特定的host_name,user_agent),然后compile(path)的工作是把path换成一个正则表达式(这样通过match就可以获得匹配的组)，还有提取keys(例如*的就变成splat，:name就变成name)。重要的是把get '/' do xxx end动态生成一个"#{verb} #{path}"的方法并最终封装成一个带有上下文状态的proc对象，最终是把[pattern, keys, conditions, block]加入@routes[verb]里边去。而call(env)能够处理请求就得靠这个@routes来实现。
先来看看 call(env) -> call!(env)，最重要的部分是invoke { dispatch! }，可以看到dispatch!的整个流程是
判断并处理static文件 -> before_filter! -> route! -> after_filter!，主要的处理过程是route!方法

Ruby代码

1.    def route!(base=self.class, pass_block=nil)
   
2.       if routes = base.routes[@request.request_method]
   
3.         original_params = @params
   
4.         path            = unescape(@request.path_info)
   
5. 
   
6.         routes.each do |pattern, keys, conditions, block|
   
7.           if match = pattern.match(path)
   
8.             values = match.captures.to_a
   
9.             params =
   
10.               if keys.any?
    
11.                 keys.zip(values).inject({}) do |hash,(k,v)|
    
12.                   if k == 'splat'
    
13.                     (hash[k] ||= []) << v
    
14.                   else
    
15.                     hash[k] = v
    
16.                   end
    
17.                   hash
    
18.                 end
    
19.               elsif values.any?
    
20.                 {'captures' => values}
    
21.               else
    
22.                 {}
    
23.               end
    
24.             @params = original_params.merge(params)
    
25.             @block_params = values
    
26. 
    
27.             pass_block = catch(:pass) do
    
28.               conditions.each { |cond|
    
29.                 throw :pass if instance_eval(&cond) == false }
    
30.               route_eval(&block)
    
31.             end
    
32.           end
    
33.         end
    
34. 
    
35.         @params = original_params
    
36.       end

复制代码

首先sinatra先从＠routes里边取得符合请求类型的[pattern, keys, conditions, block]列表，然后逐个扫描，通过pattern来match路径，如果符合的话，取得通配符，命名参数的值并封装到params去(得益于 compile(path)的工作)。接下去判断conditions是否符合，如果都符合，则执行业务，即block。整个流程处理完之后，把 params恢复为原本的状态。

2.3.拦截器
在上面已经提到，sinatra的拦截器是通过before_filter!和after_filter!来执行的，如下所示:

Ruby代码

1. def before_filter!(base=self.class)
   
2.       before_filter!(base.superclass) if base.superclass.respond_to?(:before_filters)
   
3.       base.before_filters.each { |block| instance_eval(&block) }
   
4.     end

复制代码

配置过滤器也非常简单，定义一个前置过滤器，例如

Ruby代码

1.   before do
   
2.     @note = 'Hi!'
   
3.     request.path_info = '/foo/bar/baz'
   
4.   end  

复制代码

sinatra 通过Sinatra::Base的before把block加入到@before_filters中去，这个应该很容易明白的。不过，这个拦截器功能比起 rails那个显得简陋了，毕竟不能直接针对某些路径进行拦截处理。

2.4.模板渲染
sinatra通过Tilt实现多模板的渲染机制，生成页面的过程是在业务代码块那里注明的，例如

Ruby代码

1. require 'erb'
   
2.   get '/' do
   
3.     erb :index
   
4.   end

复制代码

sinatra的模板方法是在 Sinatra::Templates模块里边定义的，能够支持erb,erubis,haml,sass,less,builder,具体的实现如下：

Ruby代码

1. def render(engine, data, options={}, locals={}, &block)
   
2.       # merge app-level options
   
3.       options = settings.send(engine).merge(options) if settings.respond_to?(engine)
   
4. 
   
5.       # extract generic options
   
6.       locals = options.delete(:locals) || locals || {}
   
7.       views = options.delete(:views) || settings.views || "./views"
   
8.       layout = options.delete(:layout)
   
9.       layout = :layout if layout.nil? || layout == true
   
10. 
    
11.       # compile and render template
    
12.       template = compile_template(engine, data, options, views)
    
13.       output = template.render(self, locals, &block)
    
14. 
    
15.       # render layout
    
16.       if layout
    
17.         begin
    
18.           options = options.merge(:views => views, :layout => false)
    
19.           output = render(engine, layout, options, locals) { output }
    
20.         rescue Errno::ENOENT
    
21.         end
    
22.       end
    
23. 
    
24.       output
    
25.     end  

复制代码

具体的流程是先找到template engine，通过template的render方法渲染子页面，然后在把子页面的内容作为一个block参数放到渲染layout的render方法上去，这样在父页面里边的yield就会被子页面的内容所取代，从而实现整体页面的渲染。

2.5.错误及状态处理
sinatra在这方面的处理，我觉得非常巧妙，还认识了一些从来没用过的api。几个重要的特性：
halt:

Ruby代码

1. halt 410
   
2.   halt 'this will be the body'
   
3.   halt 401, 'go away!'error:

复制代码

Ruby代码

1. error do
   
2.     'Sorry there was a nasty error - ' + env['sinatra.error'].name
   
3.   end
   
4.   error MyCustomError do
   
5.     'So what happened was...' + request.env['sinatra.error'].message
   
6.   end
   
7.   error 400..510 do
   
8.     'Boom'
   
9.   end

复制代码

error 的实现很简单，只是把error code和block记录到＠errors上去，而not_found其实就是404的error了。halt从代码实现上看，它是throw一个 halt的异常。

这些处理方式在sinatra最终是怎么处理的呢？我们先回到dispatch!这个主方法，从源码中可以看到如果是静态页面，会抛出halt(line 173),到了route!方法的时候，如下

Ruby代码

1.   
   
2.             pass_block = catch(:pass) do
   
3.               conditions.each { |cond|
   
4.                 throw :pass if instance_eval(&cond) == false }
   
5.                 route_eval(&block)
   
6.             end  

复制代码

catch(args,&block) 这个方法是会忽视在遇到pass异常的时候忽略异常并跳出block的运行，所以conditions验证不通过的时候，就会转入下一个pattern验证，而在验证通过后到了route_eval(&block) 就会抛出halt从而跳出循环，表示已经匹配成功。抛出异常之后会在dispatch!通过rescue来处理。error_block!(*keys) 就是用来处理error的，＠errors根据error code来获取block，这样就可以输出自定义的错误页面了

转自：http://www.javaeye.com/wiki/ruby_off_rails/2277-sinatra-analytics

Sapien

感觉 Sinatra 比 Rails 简单直观很多，不知道其功能和性能怎么样，能否用于生产环境。

2gua

框架太多，实用跟兴趣是有差距的。

bugbugbug3

Cool ~

2gua

现在，想关注下Ruby和Sinatra了。

bugbugbug3

好多网站 即用Rails,也使用Sinatra

2gua

回复 6# bugbugbug3


    你用过？

bugbugbug3

回复 7# 2gua
我是从这里知道的:
http://www.sinatrarb.com/wild.html

里面列出了使用Sinatra的应用及网站,还有公司。
比如说:GitHub就是Rails和Sinatra结合使用。

2gua

回复 8# bugbugbug3


    改天也试用一下吧。

zhlong8

今天刚知道 qiushibaike.com 这个也是用 rail 写的