Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>When you get a class to inherit from <code>Sinatra::Base</code> you are making that a Sinatra application. Each application gets <em>its own</em> <code>settings</code> object. If you want to share settings across applications you have some options:</p> <ol> <li>Merge the applications.</li> <li>Make the settings more globally accessible.</li> <li>Inheritance (see edit below)</li> </ol> <p>Merging them is easy (unless there's some particular reason we're not aware of), you basically put them in the same class.</p> <p>To make the settings more globally accessible, I'd do the following:</p> <p>a) Wrap the entire application in a module to namespace it.<br> b) Put the settings you want to use in a class instance variable accessible via a "getter" method.</p> <p>e.g.</p> <pre><code>module MyNamespace def self.global_settings @gs ||= # load your settings end class App &lt; Sinatra::Base configure do set :something_from_the_global, MyNamespace.global_settings.something end end class SecondaryApp &lt; Sinatra::Base helpers do def another_method MyNamespace.global_settings.something_else # available anywhere end end configure do # they're also available here, since you set them up before the app set :something_from_the_global, MyNamespace.global_settings.something end end end </code></pre> <p>That's fine if you've got some very small apps, but if you're using multiple apps then you'll want to separate things out a bit. The way I tend to organise an app is remove everything from the rackup file (usually <code>config.ru</code>) that does anything, aside from <code>require</code>s and <code>run</code>. I put the middleware and app setup in another file, usually <code>app/config.rb</code> so I know it's the stuff from the <code>config.ru</code>. Then each application gets its own file (e.g. <code>app/app.rb</code>, <code>app/secondary.rb</code>)</p> <pre><code># app/config.rb require "app" require "secondary" module MyNamespace # set up your getters… e.g. def self.global_settings @gs ||= # load your settings end def self.app Rack::Builder.app do # …and middleware here use SecondaryApp run App end end end # config.ru require 'rubygems' require 'bundler' Bundler.require root = File.expand_path File.dirname(__FILE__) require File.join( root , "./app/config.rb" ) map "/" do run MyNamespace.app end </code></pre> <p>There are a lot of benefits to this kind of set up - it's easier to test; it's easier to organise; you can move apps around easier. But YMMV as always.</p> <hr> <p>I should also add, as it's very remiss of me not to, that it's also possible to use inheritance, for example:</p> <pre><code>require 'sinatra/base' module MyNamespace class Controller &lt; Sinatra::Base configure :development do set :config, "some JSON" set :mtime, Time.now.to_s end end class App1 &lt; Controller get "/app1" do "in App1 config: #{settings.config} mtime: #{settings.mtime}" end end class App2 &lt; Controller get "/app2" do "in App2 with config: #{settings. config} mtime: #{settings.mtime}" end end end </code></pre> <p>Settings, routes, helpers, filters are all inherited, so if you configure something in the ancestor app it will be available in the inheritors. Sometimes it will be better to do it this way, probably when settings are just "global" to the Sinatra apps or when you want to create reusable apps and controllers. Other times, you'll need settings that can be used in models, libraries etc, and then the more global solution I've given first would be best.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload