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:
commit
1f1455008d
4 changed files with 33 additions and 18 deletions
23
README.rdoc
23
README.rdoc
|
@ -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:
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in a new issue