How to Build Sinatra on Rails 3
In Ruby, we have the great fortune to have one major framework (Rails) and a number of minor frameworks that drive innovation forward. One of the great minor frameworks which has been getting a lot of traction recently is Sinatra, primarily because it exposes a great DSL for writing small, single-purpose apps.
Here's an example of a simple Sinatra application.
class MyApp < Sinatra::Base
set :views, File.dirname(__FILE__)
enable :sessions
before do
halt if session[:fail] == true
end
get "/hello" do
"Hello world"
end
get "/world" do
@name = "Carl"
erb :awesomesauce
end
get "/fail" do
session[:fail] = true
"You failed"
end
end
There's a lot of functionality packed into this little package. You can declare some code to be run before all actions, declare actions and the URL they should be routed from, use rendering semantics, and even use sessions.
We've been saying that Rails 3 is flexible enough to use as a framework toolkit--let's prove it by using Rails to build the subset of the Sinatra DSL described above.
Let's start with a very tiny subset of the DSL:
class MyApp < Sinatra::Base
get "/hello" do
"HELLO World"
end
post "/world" do
"Hello WORLD"
end
end
The first step is to declare the Sinatra base class:
module Sinatra
class Base < ActionController::Metal
include ActionController::RackConvenience
end
end
We start off by making Sinatra::Base a subclass of the bare metal ActionController implementation, which provides just enough infrastructure to get going. We also include the RackConvenience module, which provides request
and response
and handles some basic Rack tasks for us.
Next, let's add support for the GET and POST method:
class Sinatra::Base
def self.inherited(klass)
klass.class_eval { @_routes = [] }
end
class << self
def get(uri, options = {}, &block) route(:get, uri, options, &block) end
def post(uri, options = {}, &block) route(:post, uri, options, &block) end
def route(http_method, uri, options, &block)
action_name = "[#{http_method}] #{uri}"
@_routes << {:method => http_method.to_s.upcase, :uri => uri,
:action => action_name, :options => options}
define_method(action_name, &block)
end
end
end
We've simply defined some class methods on the Sinatra::Base to store off routing details for the get
and post
methods, and creating a new method named [GET] /hello
. This is a bit of an interesting Ruby trick; while the def
keyword has strict semantics for method names, define_method
allows any string.
Now we need to wire up the actual routing. There are a number of options, including the Rails router (rack-mount, rack-router, and usher are all new, working Rails-like routers). We'll use Usher, a fast Rails-like router written by Josh Hull.
class << Sinatra::Base
def to_app
routes, controller = @_routes, self
Usher::Interface.for(:rack) do
routes.each do |route|
add(route[:uri], :conditions => {:method => route[:method]}.merge(route[:options])).
to(controller.action(route[:action]))
end
end
end
end
Here, we define to_app, which is used by Rack to convert a parameter to run
into a valid Rack application. We create a new Usher interface, and add a route for each route created by Sinatra. Because Usher::Interface.for
uses instance_eval for its DSL, we store off the routes and controller in local variables that will still be available in the closure.
One little detail here: In Rails 3, each action in a controller is a valid rack endpoint. You get the endpoint by doing ControllerName.action(method_name)
. Here, we're simply pulling out the action named "[GET] /hello" that we created in route
.
The final piece of the puzzle is covering the action processing in the controller itself. For this, we will mostly reuse the default action processing, with a small change:
class Sinatra::Base
def process_action(*)
self.response_body = super
end
end
What's happening here is that Rails does not treat the return value of the action as significant, instead expecting it to be set using render
, but Sinatra treats the returned string as significant. As a result, we set the response_body
to the return value of the action.
Next, let's add session support.
class << Sinatra::Base
def set(name, value)
send("_set_#{name}", value)
end
def enable(name)
set(name, true)
end
def _set_sessions(value)
@_sessions = value
include ActionController::Session if value
end
def to_app
routes, controller = @_routes, self
app = Usher::Interface.for(:rack) do
routes.each do |route|
add(route[:uri], :conditions => {:method => route[:method]}.merge(route[:options])).
to(controller.action(route[:action]))
end
end
if @_sessions
app = ActionDispatch::Session::CookieStore.new(app, {:key => "_secret_key",
:secret => Digest::SHA2.hexdigest(Time.now.to_s + rand(100).to_s)})
end
app
end
end
There's a few things going on here. First, Sinatra provides an API for setting options: set :option, :value
. In Sinatra, enable :option
is equivalent to set :option, true
. To simplify adding new options, we just delegate set :whatever, value
to a call to _set_whatever(value)
.
We then implement _set_sessions(value)
to include ActionController::Session
, which provides the session
helper. In to_app
, we wrap the original application in an ActionDispatch::Session::CookieStore
if sessions were set.
Next, we want to add in support for callbacks (before do
). It's only a few lines:
class Sinatra::Base
include AbstractController::Callbacks
end
class << Sinatra::Base
alias before before_filter
end
Basically, we pull in the normal Rails callback code, and then rename before_filter
to before
and we're good to go.
Finally, let's dig into rendering.
class Sinatra::Base
include ActionController::RenderingController
def sinatra_render_file(name)
render :template => name.to_s
end
def sinatra_render_inline(string, type)
render :inline => string, :type => type
end
%w(haml erb builder).each do |type|
define_method(type) do |thing|
return sinatra_render_inline(thing, type) if thing.is_a?(String)
return sinatra_render_file(thing)
end
end
end
class << Sinatra::Base
alias _set_views append_view_path
end
We include the RenderController
module, which provides rendering support. Sinatra supports a few different syntaxes for rendering. It supports erb :template_name
which renders the ERB template named template_name
. It also supports erb "Some String"
, which renders the string uses the ERB engine.
Rails supports both of those via render :template
and render :inline
, so we simply defer to that functionality in each case. We also handle Sinatra's set :views, view_path
by delegating to append_view_path.
You can check out the full repository at https://github.com/wycats/railsnatra/
So there you have it, a large subset of the Sinatra DSL written in Rails in under 100 lines of code. And if you want to add in more advanced Rails features, like layouts, flash, respond_to, file streaming, or conditional get support, it's just a simple module inclusion away.