Skip to content

Commit

Permalink
Merge branch 'extend-main'
Browse files Browse the repository at this point in the history
  • Loading branch information
rkh committed Dec 30, 2011
2 parents e111243 + 367cb3c commit 1f14550
Show file tree
Hide file tree
Showing 4 changed files with 33 additions and 18 deletions.
23 changes: 9 additions & 14 deletions README.rdoc
Expand Up @@ -1536,11 +1536,11 @@ is recommended:

Defining your app at the top-level works well for micro-apps but has
considerable drawbacks when building reusable components such as Rack
middleware, Rails metal, simple libraries with a server component, or
even Sinatra extensions. The top-level DSL pollutes the Object namespace
and assumes a micro-app style configuration (e.g., a single application
file, <tt>./public</tt> and <tt>./views</tt> directories, logging, exception
detail page, etc.). That's where <tt>Sinatra::Base</tt> comes into play:
middleware, Rails metal, simple libraries with a server component, or even
Sinatra extensions. The top-level assumes a micro-app style configuration
(e.g., a single application file, <tt>./public</tt> and <tt>./views</tt>
directories, logging, exception detail page, etc.). That's where
<tt>Sinatra::Base</tt> comes into play:

require 'sinatra/base'

Expand Down Expand Up @@ -1572,15 +1572,10 @@ for details on available options and their behavior.
Contrary to common belief, there is nothing wrong with classic style. If it
suits your application, you do not have to switch to a modular application.

There are only two downsides compared with modular style:

* You may only have one Sinatra application per Ruby process. If you plan to
use more, switch to modular style.

* Classic style pollutes Object with delegator methods. If you plan to ship
your application in a library/gem, switch to modular style.

There is no reason you cannot mix modular and classic style.
The main downsides of using classic style rather than modular style is that
you may only have one Sinatra application per Ruby process. If you plan to use
more than one, switch to modular style. There is no reason you cannot mix
modular and classic style.

If switching from one style to the other, you should be aware of slightly
different default settings:
Expand Down
4 changes: 3 additions & 1 deletion lib/sinatra/main.rb
Expand Up @@ -25,4 +25,6 @@ class Application < Base
at_exit { Application.run! if $!.nil? && Application.run? }
end

include Sinatra::Delegator
# include would include the module in Object
# extend only extends the `main` object
extend Sinatra::Delegator
16 changes: 15 additions & 1 deletion test/integration/app.rb
@@ -1,6 +1,20 @@
require 'sinatra'

configure do
set :foo, :bar
end

get '/app_file' do
content_type :txt
settings.app_file
end
end

get '/mainonly' do
object = Object.new
begin
object.send(:get, '/foo') { }
'false'
rescue NameError
'true'
end
end
8 changes: 6 additions & 2 deletions test/integration_test.rb
Expand Up @@ -57,9 +57,13 @@ def with_server
raise error || e
end

it 'starts a top level application' do
def assert_content(url, content)
with_server do
assert_equal open("http://127.0.0.1:#{port}/app_file").read, app_file
response = open("http://127.0.0.1:#{port}#{url}")
assert_equal response.read, content
end
end

it('sets the app_file') { assert_content "/app_file", app_file }
it('only extends main') { assert_content "/mainonly", "true" }
end

0 comments on commit 1f14550

Please sign in to comment.