sinatra 1.2.9 → 1.3.0.a

data/README.fr.rdoc

@@ -894,8 +894,8 @@ souhaitez obtenir le résultat d'une autre route. Pour cela, utilisez
 simplement +call+ :
 
   get '/foo' do
-    status, headers, body = call env.merge("PATH_INFO" => '/bar')
-    [status, headers, body.map(&:upcase)]
+    status, headers, body = call request.env.merge("PATH_INFO" => '/bar')
+    [status, body.upcase]
   end
 
   get '/bar' do
@@ -940,7 +940,7 @@ retour et les entêtes :
   get '/foo' do
     status 418
     headers \
-      "Allow"   => "BREW, POST, GET, PROPFIND, WHEN",
+      "Allow"   => "BREW, POST, GET, PROPFIND, WHEN"
       "Refresh" => "Refresh: 20; http://www.ietf.org/rfc/rfc2324.txt"
     body "I'm a tea pot!"
   end
@@ -1008,7 +1008,7 @@ Pour passer des arguments à une redirection, ajoutez-les soit à la requête :
 
 Ou bien utilisez une session :
 
-  enable :sessions
+  enable :session
 
   get '/foo' do
     session[:secret] = 'foo'
@@ -1399,7 +1399,7 @@ variable Rack <tt>sinatra.error</tt>:
 Erreur sur mesure:
 
   error MonErreurSurMesure do
-    'Donc il est arrivé ceci...' + env['sinatra.error'].message
+    'Donc il est arrivé ceci...' + request.env['sinatra.error'].message
   end
 
 Donc si ceci arrive:
@@ -1595,7 +1595,7 @@ Ou alors avec un fichier <tt>config.ru</tt>, qui permet d'utiliser n'importe
 quel gestionnaire Rack :
 
   # config.ru
-  require './my_app'
+  require 'my_app'
   run MyApp
 
 Exécutez :
@@ -1615,7 +1615,7 @@ Ecrivez votre application :
 
 Et un fichier <tt>config.ru</tt> correspondant :
 
-  require './app'
+  require 'app'
   run Sinatra::Application
 
 === Quand utiliser un fichier config.ru ?

data/README.hu.rdoc

@@ -399,7 +399,7 @@ előszűrő kivételt vált ki. A kivétel objektum lehívható a
 Egyéni hibakezelés:
 
   error MyCustomError do
-    'Szóval az van, hogy...' + env['sinatra.error'].message
+    'Szóval az van, hogy...' + request.env['sinatra.error'].message
   end
 
 És amikor fellép:

data/README.jp.rdoc

@@ -67,12 +67,6 @@ Sinatraでは、ルートはHTTPメソッドとURLマッチングパターンが
     params[:splat] # => ["path/to/file", "xml"]
   end
 
-ブロックパラーメータを使用した場合:
-
-  get '/download/*.*' do |path, ext|
-    [path, ext] # => ["path/to/file", "xml"]
-  end
-
 正規表現を使ったルート:
 
   get %r{/hello/([\w]+)} do
@@ -706,7 +700,7 @@ body部を指定することもできます ...
 エラーをカスタマイズする場合は、
 
   error MyCustomError do
-    'エラーメッセージ...' + env['sinatra.error'].message
+    'エラーメッセージ...' + request.env['sinatra.error'].message
   end
 
 と書いておいて,下記のように呼び出します。
@@ -996,7 +990,7 @@ Sinatraの開発版を使いたい場合は、ローカルに開発版を落と
   git clone git://github.com/sinatra/sinatra.git
   ruby -Isinatra/lib myapp.rb
 
-<tt>sinatra/lib</tt>ディレクトリをアプリケーションの<tt>LOAD_PATH</tt>に追加する方法もあります。
+<tt>sinatra/lib</tt>ディレクトリをto the<tt>LOAD_PATH</tt>に追加する方法もあります。
 
   $LOAD_PATH.unshift File.dirname(__FILE__) + '/sinatra/lib'
   require 'rubygems'

data/README.pt-br.rdoc

@@ -431,7 +431,7 @@ Rack <tt>sinatra.error</tt>:
 Erros customizados:
 
   error MeuErroCustomizado do
-    'Então que aconteceu foi...' + env['sinatra.error'].message
+    'Então que aconteceu foi...' + request.env['sinatra.error'].message
   end
 
 Então, se isso acontecer:

data/README.pt-pt.rdoc

@@ -430,7 +430,7 @@ Rack <tt>sinatra.error</tt>:
 Erros personalizados:
 
   error MeuErroPersonalizado do
-    'O que aconteceu foi...' + env['sinatra.error'].message
+    'O que aconteceu foi...' + request.env['sinatra.error'].message
   end
 
 Então, se isso acontecer:

data/README.rdoc

@@ -1,8 +1,5 @@
 = Sinatra
 
-<i>This is a backports release. If you have no reason to remain at Sinatra 1.2,
-please consider upgrading.</i>
-
 Sinatra is a DSL for quickly creating web applications in Ruby with minimal
 effort:
 
@@ -37,13 +34,17 @@ Each route is associated with a block:
   end
 
   put '/' do
-    .. update something ..
+    .. replace something ..
+  end
+
+  patch '/' do
+    .. modify something ..
   end
 
   delete '/' do
     .. annihilate something ..
   end
-  
+
   options '/' do
     .. appease something ..
   end
@@ -79,12 +80,6 @@ via the <tt>params[:splat]</tt> array:
     params[:splat] # => ["path/to/file", "xml"]
   end
 
-Or with block parameters:
-
-  get '/download/*.*' do |path, ext|
-    [path, ext] # => ["path/to/file", "xml"]
-  end
-
 Route matching with Regular Expressions:
 
   get %r{/hello/([\w]+)} do
@@ -97,12 +92,6 @@ Or with a block parameter:
     "Hello, #{c}!"
   end
 
-Route patterns may have optional parameters:
-
-  get '/posts.?:format?' do
-    # matches "GET /posts" and any extension "GET /posts.json", "GET /posts.xml" etc.
-  end
-
 === Conditions
 
 Routes may include a variety of matching conditions, such as the user agent:
@@ -140,25 +129,7 @@ You can easily define your own conditions:
   get '/win_a_car' do
     "Sorry, you lost."
   end
-  
-For a condition that takes multiple values use a splat:
 
-  set(:auth) do |*roles|   # <- notice the splat here
-    condition do
-      unless logged_in? && roles.any? {|role| current_user.in_role? role }
-        redirect "/login/", 303 
-      end
-    end
-  end
-
-  get "/my/account/", :auth => [:user, :admin] do
-    "Your Account Details"
-  end
-  
-  get "/only/admin/", :auth => :admin do
-    "Only admins are allowed here!"
-  end
-  
 === Return Values
 
 The return value of a route block determines at least the response body passed
@@ -659,7 +630,7 @@ Or, specify an explicit Hash of local variables:
 
   get '/:id' do
     foo = Foo.find(params[:id])
-    haml '%h1= bar.name', :locals => { :bar => foo }
+    haml '%h1= foo.name', :locals => { :foo => foo }
   end
 
 This is typically used when rendering templates as partials from within
@@ -801,20 +772,6 @@ route handlers and templates:
     bar(params[:name])
   end
 
-Alternatively, helper methods can be separately defined in a module:
-
-  module FooUtils
-    def foo(name) "#{name}foo" end
-  end
-
-  module BarUtils
-    def bar(name) "#{name}bar" end
-  end
-
-  helpers FooUtils, BarUtils
-
-The effect is the same as including the modules in the application class.
-
 === Using Sessions
 
 A session is used to keep state during requests. If activated, you have one
@@ -832,9 +789,9 @@ session hash per user session:
 
 Note that <tt>enable :sessions</tt> actually stores all data in a cookie. This
 might not always be what you want (storing lots of data will increase your
-traffic, for instance). You can use any Rack session middleware: in order to
+traffic, for instance). You can use any Rack session middleware, in order to
 do so, do *not* call <tt>enable :sessions</tt>, but instead pull in your
-middleware of choice as you would any other middleware:
+middleware of choice how you would any other middleware:
 
   use Rack::Session::Pool, :expire_after => 2592000
 
@@ -853,6 +810,11 @@ set the secret yourself, so all your application instances share it:
 
   set :session_secret, 'super secret'
 
+If you want to configure it further, you may also store a hash with options in
+the +sessions+ setting:
+
+  set :sessions, :domain => 'foo.com'
+
 === Halting
 
 To immediately stop a request within a filter or route use:
@@ -901,8 +863,8 @@ Sometimes +pass+ is not what you want, instead you would like to get the result
 of calling another route. Simply use +call+ to achieve this:
 
   get '/foo' do
-    status, headers, body = call env.merge("PATH_INFO" => '/bar')
-    [status, headers, body.map(&:upcase)]
+    status, headers, body = call request.env.merge("PATH_INFO" => '/bar')
+    [status, body.upcase]
   end
 
   get '/bar' do
@@ -942,7 +904,7 @@ Similar to the body, you can also set the status code and headers:
   get '/foo' do
     status 418
     headers \
-      "Allow"   => "BREW, POST, GET, PROPFIND, WHEN",
+      "Allow"   => "BREW, POST, GET, PROPFIND, WHEN"
       "Refresh" => "Refresh: 20; http://www.ietf.org/rfc/rfc2324.txt"
     body "I'm a tea pot!"
   end
@@ -950,14 +912,35 @@ Similar to the body, you can also set the status code and headers:
 Like +body+, +headers+ and +status+ with no arguments can be used to access
 their current values.
 
+=== Logging
+
+In the request scope, the +logger+ helper exposes a +Logger+ instance:
+
+  get '/' do
+    logger.info "loading data"
+    # ...
+  end
+
+This logger will automatically take your Rack handler's logging settings into
+account. If logging is disabled, this method will return a dummy object, so
+you do not have to worry in your routes and filters about it.
+
+Note that logging is only enabled for <tt>Sinatra::Application</tt> by
+default, so if you inherit from <tt>Sinatra::Base</tt>, you probably want to
+enable it yourself:
+
+  class MyApp < Sinatra::Base
+    configure(:production, :development) do
+      enable :logging
+    end
+  end
+
 === Mime Types
 
 When using <tt>send_file</tt> or static files you may have mime types Sinatra
 doesn't understand. Use +mime_type+ to register them by file extension:
 
-  configure do
-    mime_type :foo, 'text/foo'
-  end
+  mime_type :foo, 'text/foo'
 
 You can also use it with the +content_type+ helper:
 
@@ -1008,7 +991,7 @@ To pass arguments with a redirect, either add them to the query:
 
 Or use a session:
 
-  enable :sessions
+  enable :session
   
   get '/foo' do
     session[:secret] = 'foo'
@@ -1318,8 +1301,7 @@ You can access those options via <tt>settings</tt>:
 [public]              folder public files are served from
 
 [reload_templates]    whether or not to reload templates between requests.
-                      Enabled in development mode and on Ruby 1.8.6 (to
-                      compensate a bug in Ruby causing a memory leak).
+                      Enabled in development mode.
 
 [root]                project root folder.
 
@@ -1374,7 +1356,7 @@ block or a filter. The exception object can be obtained from the
 Custom errors:
 
   error MyCustomError do
-    'So what happened was...' + env['sinatra.error'].message
+    'So what happened was...' + request.env['sinatra.error'].message
   end
 
 Then, if this happens:
@@ -1441,16 +1423,10 @@ debugging, URL routing, authentication, and session handling. Sinatra uses
 many of these components automatically based on configuration so you
 typically don't have to +use+ them explicitly.
 
-You can find useful middleware in
-{rack}[https://github.com/rack/rack/tree/master/lib/rack],
-{rack-contrib}[https://github.com/rack/rack-contrib#readme],
-with {CodeRack}[http://coderack.org/] or in the
-{Rack wiki}[https://github.com/rack/rack/wiki/List-of-Middleware].
-
 == Testing
 
 Sinatra tests can be written using any Rack-based testing library
-or framework. {Rack::Test}[http://rdoc.info/github/brynary/rack-test/master/frames] is
+or framework. {Rack::Test}[http://gitrdoc.com/brynary/rack-test] is
 recommended:
 
   require 'my_sinatra_app'
@@ -1480,6 +1456,9 @@ recommended:
     end
   end
 
+NOTE: The built-in Sinatra::Test module and Sinatra::TestHarness class
+are deprecated as of the 0.9.2 release.
+
 == Sinatra::Base - Middleware, Libraries, and Modular Apps
 
 Defining your app at the top-level works well for micro-apps but has
@@ -1487,8 +1466,8 @@ 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:
+file, ./public and ./views directories, logging, exception detail page,
+etc.). That's where Sinatra::Base comes into play:
 
   require 'sinatra/base'
 
@@ -1501,15 +1480,15 @@ detail page, etc.). That's where <tt>Sinatra::Base</tt> comes into play:
     end
   end
 
-The methods available to <tt>Sinatra::Base</tt> subclasses are exactly as those
+The methods available to Sinatra::Base subclasses are exactly as those
 available via the top-level DSL. Most top-level apps can be converted to
-<tt>Sinatra::Base</tt> components with two modifications:
+Sinatra::Base components with two modifications:
 
 * Your file should require <tt>sinatra/base</tt> instead of +sinatra+;
   otherwise, all of Sinatra's DSL methods are imported into the main
   namespace.
 * Put your app's routes, error handlers, filters, and options in a subclass
-  of <tt>Sinatra::Base</tt>.
+  of Sinatra::Base.
 
 <tt>Sinatra::Base</tt> is a blank slate. Most options are disabled by default,
 including the built-in server. See {Options and Configuration}[http://sinatra.github.com/configuration.html]
@@ -1530,8 +1509,8 @@ There are only two downsides compared with 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:
+If switching from one style to the other, you should be aware of slight
+differences in the setting:
 
   Setting             Classic                 Modular
 
@@ -1564,7 +1543,7 @@ Start with:
 Or with a <tt>config.ru</tt>, which allows using any Rack handler:
 
   # config.ru
-  require './my_app'
+  require 'my_app'
   run MyApp
 
 Run:
@@ -1584,7 +1563,7 @@ Write your app file:
 
 And a corresponding <tt>config.ru</tt>:
 
-  require './app'
+  require 'app'
   run Sinatra::Application
 
 === When to use a config.ru?
@@ -1615,7 +1594,7 @@ application (Rails/Ramaze/Camping/...):
     get('/login') { haml :login }
     
     post('/login') do
-      if params[:name] == 'admin' && params[:password] == 'admin'
+      if params[:name] = 'admin' and params[:password] = 'admin'
         session['user_name'] = params[:name]
       else
         redirect '/login'
@@ -1636,46 +1615,6 @@ application (Rails/Ramaze/Camping/...):
     get('/') { "Hello #{session['user_name']}." }
   end
 
-=== Dynamic Application Creation
-
-Sometimes you want to create new applications at runtime without having to
-assign them to a constant, you can do this with <tt>Sinatra.new</tt>:
-
-  require 'sinatra/base'
-  my_app = Sinatra.new { get('/') { "hi" } }
-  my_app.run!
-
-It takes the application to inherit from as optional argument:
-
-  # config.ru
-  require 'sinatra/base'
-
-  controller = Sinatra.new do
-    enable :logging
-    helpers MyHelpers
-  end
-
-  map('/a') do
-    run Sinatra.new(controller) { get('/') { 'a' } }
-  end
-
-  map('/b') do
-    run Sinatra.new(controller) { get('/') { 'b' } }
-  end
-
-This is especially useful for testing Sinatra extensions or using Sinatra in
-your own library.
-
-This also makes using Sinatra as middleware extremely easy:
-
-  require 'sinatra/base'
-
-  use Sinatra do
-    get('/') { ... }
-  end
-
-  run RailsProject::Application
-
 == Scopes and Binding
 
 The scope you are currently in determines what methods and variables are
@@ -1683,9 +1622,9 @@ available.
 
 === Application/Class Scope
 
-Every Sinatra application corresponds to a subclass of <tt>Sinatra::Base</tt>. If you
+Every Sinatra application corresponds to a subclass of Sinatra::Base. If you
 are using the top-level DSL (<tt>require 'sinatra'</tt>), then this class is
-<tt>Sinatra::Application</tt>, otherwise it is the subclass you created explicitly. At
+Sinatra::Application, otherwise it is the subclass you created explicitly. At
 class level you have methods like +get+ or +before+, but you cannot access the
 +request+ object or the +session+, as there only is a single application class
 for all requests.
@@ -1708,7 +1647,6 @@ You have the application scope binding inside:
 * Methods defined by extensions
 * The block passed to +helpers+
 * Procs/blocks used as value for +set+
-* The block passed to <tt>Sinatra.new</tt>
 
 You can reach the scope object (the class) like this:
 
@@ -1778,21 +1716,10 @@ Options are:
   -s # specify rack server/handler (default is thin)
   -x # turn on the mutex lock (default is off)
 
-== Requirements
-
-It is recommended to install Sinatra on Ruby 1.8.7, 1.9.2, JRuby or Rubinius.
+== Requirement
 
 The following Ruby versions are officially supported:
 
-[ Ruby 1.8.6 ]
-  It is not recommended to use 1.8.6 for Sinatra. However, it is still supported
-  in Sinatra 1.2 (this version), it has been dropped in Sinatra 1.3.0, though.
-  RDoc and CoffeeScript templates are not supported. 1.8.6 includes a major
-  memory leak in its Hash implementation, which is triggered by Sinatra versions
-  prior to 1.1.1. The current version explicitly prevents this leak at the cost
-  of performance. You will have to downgrade Rack to 1.1.x, as Rack >= 1.2 no
-  longer supports 1.8.6.
-
 [ Ruby 1.8.7 ]
   1.8.7 is fully supported, however, if nothing is keeping you from it, we
   recommend upgrading to 1.9.2 or switching to JRuby or Rubinius.
@@ -1813,6 +1740,8 @@ The following Ruby versions are officially supported:
   on JRuby. JRuby's support for C extensions is still experimental, which only
   affects RDiscount at the moment.
 
+<b>Ruby 1.8.6 is no longer supported.</b>
+
 We also keep an eye on upcoming Ruby versions.
 
 The following Ruby implementations are not officially supported but still are
@@ -1821,6 +1750,7 @@ known to run Sinatra:
 * Older versions of JRuby and Rubinius
 * MacRuby, Maglev, IronRuby
 * Ruby 1.9.0 and 1.9.1
+* Ruby 1.8.6 with {backports}[https://github.com/marcandre/backports/#readme]
 
 Not being officially supported means if things only break there and not on a
 supported platform, we assume it's not our issue but theirs.
@@ -1908,9 +1838,4 @@ SemVerTag.
 * {Twitter}[http://twitter.com/sinatra]
 * {Mailing List}[http://groups.google.com/group/sinatrarb/topics]
 * {IRC: #sinatra}[irc://chat.freenode.net/#sinatra] on http://freenode.net
-* {Sinatra Book}[http://sinatra-book.gittr.com] Cookbook Tutorial
-* {Sinatra Book Contrib}[http://sinatra-book-contrib.com/] Community contributed recipes
-* API documentation for the {latest release}[http://rubydoc.info/gems/sinatra]
-  or the {current HEAD}[http://rubydoc.info/github/sinatra/sinatra] on
-  http://rubydoc.info/