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.