CODEWITHSUNDEEP
rubysinatra
pitosalas
pitosalas

Reputation: 10882

Organizing Sinatra "routing blocks" over multiple files

Any non-trivial Sinatra app will have more "routes" than one would want to put in one big Sinatra::Base descendant class. Say I wanted to put them in another class, what is idiomatic? What is that other class descended from? How do I "include" it in the main Sinatra class?

Upvotes: 2

Views: 652

Answers (2)

ian
ian

Reputation: 12251

To give another way of doing things, you can always organise them by their use, for example:

class Frontend < Sinatra::Base
  # routes here
  get "/" do #…
end


class Admin < Sinatra:Base
  # routes with a different focus here

  # You can also have things that wouldn't apply elsewhere
  # From the docs
  set(:auth) do |*roles|   # <- notice the splat here
    condition do
      unless logged_in? && roles.any? {|role| current_user.in_role? role }
        redirect "/login/", 303
      end
    end
  end

  get "/my/account/", :auth => [:user, :admin] do
    "Your Account Details"
  end

  get "/only/admin/", :auth => :admin do
    "Only admins are allowed here!"
  end
end

You can even set up a base class and inherit from that:

module MyAmazingApp
  class Base < Sinatra::Base
    # a helper you want to share
    helpers do
      def title=nil
        # something here…
      end
    end

    # standard route (see the example from
    # the book Sinatra Up and Running)
    get '/about' do
      "this is a general app"
    end
  end

  class Frontend < Base
    get '/about' do
      "this is actually the front-end"
    end
  end

  class Admin < Base
    #…
  end
end

Of course, each of these classes can be split into separate files if you wish. One way to run them:

# config.ru

map("/") do
  run MyAmazingApp::Frontend
end

# This would provide GET /admin/my/account/
# and GET /admin/only/admin/
map("/admin") do
  MyAmazingApp::Admin
end

There are other ways, I suggest you get hold of that book or check out a few blog posts (some of the high scorers for this tag are a good place to start).

Upvotes: 4

max pleaner
max pleaner

Reputation: 26778

You can just re-open the class in different files.

# file_a.rb

require 'sinatra'
require_relative "./file_b.rb"

class App < Sinatra::Base
  get("/a") { "route a" }
  run!
end

# file_b.rb

class App < Sinatra::Base
  get("/b") { "route b" }
end

If you really want different classes you can do something like this, but it's a little ugly:

# file_a.rb

require 'sinatra'
require_relative "./file_b.rb"

class App < Sinatra::Base
  get("/a") { "route a" }
  extend B
  run!
end

# file_b.rb

module B
  def self.extended(base)
    base.class_exec do
      get("/b") { "route b" }
    end
  end
end

I'm pretty sure these two are the easiest ways to do it. When you look inside the source code of how Sinatra actually adds routes from a method like get, it's pretty hairy.

I guess you could also do something goofy like this, but I wouldn't exactly call it idiomatic:

# file_a.rb

require 'sinatra'

class App < Sinatra::Base
  get("/a") { "route a" }
  eval File.read("./file_b.rb")
  run!
end

# file_b.rb

get("/b") { "route b" }

Upvotes: 6

Related Questions