1
0
Fork 0
mirror of https://github.com/sinatra/sinatra synced 2023-03-27 23:18:01 -04:00

Merge branch 'extend-main'

This commit is contained in:
Konstantin Haase 2011-12-30 22:22:54 +01:00
commit 1f1455008d
4 changed files with 33 additions and 18 deletions

View file

@ -1536,11 +1536,11 @@ is recommended:
Defining your app at the top-level works well for micro-apps but has Defining your app at the top-level works well for micro-apps but has
considerable drawbacks when building reusable components such as Rack considerable drawbacks when building reusable components such as Rack
middleware, Rails metal, simple libraries with a server component, or middleware, Rails metal, simple libraries with a server component, or even
even Sinatra extensions. The top-level DSL pollutes the Object namespace Sinatra extensions. The top-level assumes a micro-app style configuration
and assumes a micro-app style configuration (e.g., a single application (e.g., a single application file, <tt>./public</tt> and <tt>./views</tt>
file, <tt>./public</tt> and <tt>./views</tt> directories, logging, exception directories, logging, exception detail page, etc.). That's where
detail page, etc.). That's where <tt>Sinatra::Base</tt> comes into play: <tt>Sinatra::Base</tt> comes into play:
require 'sinatra/base' require 'sinatra/base'
@ -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 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. suits your application, you do not have to switch to a modular application.
There are only two downsides compared with modular 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
* You may only have one Sinatra application per Ruby process. If you plan to more than one, switch to modular style. There is no reason you cannot mix
use more, switch to modular style. modular and classic 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.
If switching from one style to the other, you should be aware of slightly If switching from one style to the other, you should be aware of slightly
different default settings: different default settings:

View file

@ -25,4 +25,6 @@ module Sinatra
at_exit { Application.run! if $!.nil? && Application.run? } at_exit { Application.run! if $!.nil? && Application.run? }
end end
include Sinatra::Delegator # include would include the module in Object
# extend only extends the `main` object
extend Sinatra::Delegator

View file

@ -1,6 +1,20 @@
require 'sinatra' require 'sinatra'
configure do
set :foo, :bar
end
get '/app_file' do get '/app_file' do
content_type :txt content_type :txt
settings.app_file settings.app_file
end end
get '/mainonly' do
object = Object.new
begin
object.send(:get, '/foo') { }
'false'
rescue NameError
'true'
end
end

View file

@ -57,9 +57,13 @@ class IntegrationTest < Test::Unit::TestCase
raise error || e raise error || e
end end
it 'starts a top level application' do def assert_content(url, content)
with_server do 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
end end
it('sets the app_file') { assert_content "/app_file", app_file }
it('only extends main') { assert_content "/mainonly", "true" }
end end