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
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'
@ -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:

View file

@ -25,4 +25,6 @@ module Sinatra
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

View file

@ -1,6 +1,20 @@
require 'sinatra'
configure do
set :foo, :bar
end
get '/app_file' do
content_type :txt
settings.app_file
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
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