RubyGems - sinatra - Versions diffs - 1.3.6 → 1.4.0.a - Mend

sinatra 1.3.6 → 1.4.0.a

Potentially problematic release.

This version of sinatra might be problematic. Click here for more details.

Files changed (71) hide show

data/CHANGES +96 -22
data/Gemfile +11 -3
data/README.de.md +2590 -0
data/README.es.rdoc +66 -38
data/README.fr.md +2630 -0
data/README.hu.rdoc +3 -2
data/README.jp.rdoc +16 -3
data/README.ko.rdoc +11 -5
data/README.md +2699 -0
data/README.pt-br.rdoc +152 -21
data/README.pt-pt.rdoc +3 -2
data/README.ru.md +2724 -0
data/README.zh.rdoc +3 -3
data/Rakefile +3 -4
data/examples/chat.rb +3 -3
data/lib/sinatra/base.rb +433 -247
data/lib/sinatra/main.rb +4 -2
data/lib/sinatra/showexceptions.rb +6 -1
data/lib/sinatra/version.rb +1 -1
data/test/base_test.rb +21 -9
data/test/builder_test.rb +15 -19
data/test/coffee_test.rb +4 -6
data/test/compile_test.rb +154 -0
data/test/contest.rb +4 -6
data/test/creole_test.rb +5 -5
data/test/delegator_test.rb +1 -3
data/test/erb_test.rb +32 -20
data/test/extensions_test.rb +1 -3
data/test/filter_test.rb +65 -56
data/test/haml_test.rb +34 -26
data/test/helpers_test.rb +331 -221
data/test/integration_helper.rb +8 -0
data/test/integration_test.rb +3 -1
data/test/less_test.rb +10 -8
data/test/liquid_test.rb +22 -4
data/test/mapped_error_test.rb +122 -96
data/test/markaby_test.rb +5 -5
data/test/markdown_test.rb +5 -5
data/test/middleware_test.rb +3 -3
data/test/nokogiri_test.rb +4 -6
data/test/rabl_test.rb +89 -0
data/test/radius_test.rb +4 -4
data/test/rdoc_test.rb +7 -7
data/test/readme_test.rb +14 -30
data/test/request_test.rb +15 -0
data/test/response_test.rb +3 -4
data/test/result_test.rb +11 -33
data/test/route_added_hook_test.rb +10 -10
data/test/routing_test.rb +123 -1
data/test/sass_test.rb +26 -26
data/test/scss_test.rb +16 -16
data/test/server_test.rb +2 -2
data/test/settings_test.rb +48 -4
data/test/sinatra_test.rb +2 -7
data/test/slim_test.rb +37 -23
data/test/static_test.rb +56 -15
data/test/streaming_test.rb +11 -2
data/test/templates_test.rb +117 -45
data/test/textile_test.rb +9 -9
data/test/views/hello.rabl +2 -0
data/test/views/hello.wlang +1 -0
data/test/views/hello.yajl +1 -0
data/test/views/layout2.rabl +3 -0
data/test/views/layout2.wlang +2 -0
data/test/wlang_test.rb +87 -0
data/test/yajl_test.rb +86 -0
metadata +27 -17
data/README.de.rdoc +0 -2097
data/README.fr.rdoc +0 -2036
data/README.rdoc +0 -2017
data/README.ru.rdoc +0 -1785

data/README.ru.rdoc DELETED

@@ -1,1785 +0,0 @@
-= Sinatra
-<i>Внимание: Этот документ является переводом английской версии и может быть устаревшим</i>
-Sinatra — это предметно-ориентированный каркас (DSL) для быстрого создания функциональных веб-приложений на Ruby:
-  # myapp.rb
-  require 'sinatra'
-  get '/' do
-    'Hello world!'
-  end
-Установите gem:
-  gem install sinatra
-и запустите приложение с помощью:
-  ruby -rubygems myapp.rb
-Результат можно увидеть: http://localhost:4567
-Рекомендуется также установить thin, сделать это можно командой: <tt>gem install thin</tt>.
-Thin - это более производительный и функциональный сервер для разработки приложений на Sinatra.
-== Маршруты
-В Sinatra маршрут — это пара: <HTTP метод> и <шаблон URL>.
-Каждый маршрут ассоциирован с блоком кода, исполняемого внутри, пример:
-  get '/' do
-    .. что-то показать ..
-  end
-  post '/' do
-    .. что-то создать ..
-  end
-  put '/' do
-    .. что-то заменить ..
-  end
-  patch '/' do
-    .. что-то изменить ..
-  end
-  delete '/' do
-    .. что-то удалить ..
-  end
-  options '/' do
-    .. что-то ответить ..
-  end
-Маршруты сверяются с запросом в порядке очередности их записи в файле приложения. По умолчанию
-будет вызван первый совпавший с запросом маршрут.
-Шаблоны маршрутов могут включать в себя параметры доступные в
-<tt>params</tt> xэше:
-  get '/hello/:name' do
-    # соответствует "GET /hello/foo" и "GET /hello/bar",
-    # где params[:name] 'foo' или 'bar'
-    "Hello #{params[:name]}!"
-  end
-Можно также использовать именные параметры в переменных блоков:
-  get '/hello/:name' do |n|
-    "Hello #{n}!"
-  end
-Шаблоны маршрутов также могут включать splat (или '*' маску, обозначающую любой символ) параметры доступные
-в массиве <tt>params[:splat]</tt>:
-  get '/say/*/to/*' do
-    # соответствует /say/hello/to/world
-    params[:splat] # => ["hello", "world"]
-  end
-  get '/download/*.*' do
-    # соответствует /download/path/to/file.xml
-    params[:splat] # => ["path/to/file", "xml"]
-  end
-Или с параметрами блока:
-  get '/download/*.*' do |path, ext|
-    [path, ext] # => ["path/to/file", "xml"]
-  end
-Маршруты также могут содержать регулярные выражения:
-  get %r{/hello/([\w]+)} do
-    "Hello, #{params[:captures].first}!"
-  end
-Или с параметром блока:
-  get %r{/hello/([\w]+)} do |c|
-    "Hello, #{c}!"
-  end
-=== Условия
-Маршруты могут включать различные условия совпадений, такие как user agent:
-  get '/foo', :agent => /Songbird (\d\.\d)[\d\/]*?/ do
-    "You're using Songbird version #{params[:agent][0]}"
-  end
-  get '/foo' do
-    # соответствует non-songbird браузерам
-  end
-Другими доступными условиями являются +host_name+ и +provides+:
-  get '/', :host_name => /^admin\./ do
-    "Admin Area, Access denied!"
-  end
-  get '/', :provides => 'html' do
-    haml :index
-  end
-  get '/', :provides => ['rss', 'atom', 'xml'] do
-    builder :feed
-  end
-Вы можете задать собственные условия:
-  set(:probability) { |value| condition { rand <= value } }
-  get '/win_a_car', :probability => 0.1 do
-    "You won!"
-  end
-  get '/win_a_car' do
-    "Sorry, you lost."
-  end
-=== Возвращаемые значения
-Возвращаемое значение блока маршрута ограничивается телом ответа, которое будет передано HTTP клиенту,
-или следующей "прослойкой" (middleware) в Rack стеке. Чаще всего это строка, как в примерах выше.
-Но и другие значения также приемлемы.
-Вы можете вернуть любой объект, который будет либо корректным Rack ответом, объектом Rack body,
-либо кодом состояния HTTP:
-* массив с тремя переменными: <tt>[status (Fixnum), headers (Hash), response body (должен отвечать на #each)]</tt>;
-* массив с двумя переменными: <tt>[status (Fixnum), response body (должен отвечать на #each)]</tt>;
-* объект, отвечающий на <tt>#each</tt>, который передает только строковые типы данных в этот блок;
-* Fixnum, представляющий код состояния HTTP.
-Таким образом, мы легко можем создать поточный пример:
-    class Stream
-      def each
-        100.times { |i| yield "#{i}\n" }
-      end
-    end
-    get('/') { Stream.new }
-=== Собственные детекторы совпадений для маршрутов
-Как показано выше, Sinatra поставляется со встроенной поддержкой строк и
-регулярных выражений в качестве шаблонов URL. Но и это еще не все. Вы можете
-легко определить свои собственные детекторы совпадений (matchers) для маршрутов:
-  class AllButPattern
-    Match = Struct.new(:captures)
-    def initialize(except)
-      @except   = except
-      @captures = Match.new([])
-    end
-    def match(str)
-      @captures unless @except === str
-    end
-  end
-  def all_but(pattern)
-    AllButPattern.new(pattern)
-  end
-  get all_but("/index") do
-    # ...
-  end
-Заметьте, что предыдущий пример возможно чересчур сложен, он также может быть представлен как:
-  get // do
-    pass if request.path_info == "/index"
-    # ...
-  end
-Или с использованием негативного просмотра вперед:
-  get %r{^(?!/index$)} do
-    # ...
-  end
-== Статические файлы
-Статические файлы отдаются из <tt>./public</tt> директории. Вы можете указать другое место,
-указав его через опцию <tt>:public_folder</tt>:
-  set :public_folder, File.dirname(__FILE__) + '/static'
-Учтите, что имя директории со статическими файлами не включено в URL. Например, файл
-<tt>./public/css/style.css</tt> будет доступен как
-<tt>http://example.com/css/style.css</tt>.
-Используйте опцию <tt>:static_cache_control</tt> (см. ниже), чтобы
-добавить заголовок <tt>Cache-Control</tt>.
-== Представления / Шаблоны
-Каждый шаблонизатор представлен своим собственным методом. Эти методы
-попросту возвращают строку:
-  get '/' do
-    erb :index
-  end
-Отобразит <tt>views/index.erb</tt>.
-Вместо имени шаблона вы так же можете передавать непосредственно само
-содержимое шаблона
-  get '/' do
-    code = "<%= Time.now %>"
-    erb code
-  end
-Эти методы принимают второй аргумент, хеш с опциями:
-  get '/' do
-    erb :index, :layout => :post
-  end
-Отобразит <tt>views/index.erb</tt>, вложенным в
-<tt>views/post.erb</tt> (по умолчанию: <tt>views/layout.erb</tt>, если существует).
-Любые опции, не понимаемые Sinatra, будут переданы в шаблонизатор
-  get '/' do
-    haml :index, :format => :html5
-  end
-Вы также можете задавать опции для шаблонизаторов в общем:
-  set :haml, :format => :html5
-  get '/' do
-    haml :index
-  end
-Опции, переданные в метод, переопределяют опции, заданные с помощью
-+set+.
-Доступные опции:
-[locals]
-  Список локальных переменных, передаваемых в документ.
-  Например: <tt>erb "<%= foo %>", :locals => {:foo => "bar"}</tt>
-[default_encoding]
-  Кодировка, которую следует использовать, если не удалось определить
-  оригинальную. По умолчанию: <tt>settings.default_encoding</tt>.
-[views]
-  Директория с шаблонами. По умолчанию: <tt>settings.views</tt>.
-[layout]
-  Использовать или нет лэйаут (+true+ или +false+). Если же значение Symbol,
-  то указывает, какой шаблон использовать в качестве лэйаута. Например:
-  <tt>erb :index, :layout => !request.xhr?</tt>
-[content_type]
-  Content-Type отображенного шаблона. По умолчанию: задается шаблонизатором.
-[scope]
-  Область видимости, в которой рендерятся шаблоны. По умолчанию: экземпляр
-  приложения. Если вы измените эту опцию, то переменные экземпляра и
-  методы-помощники станут недоступными в ваших шаблонах.
-[layout_engine]
-  Шаблонизатор, который следует использовать для отображения лэйаута. Полезная
-  опция для шаблонизаторов, в которых нет никакой поддержки лэйаутов. По
-  умолчанию: тот же шаблонизатор, что используется и для самого шаблона.
-  Пример: <tt>set :rdoc, :layout_engine => :erb</tt>
-По умолчанию считается, что шаблоны находятся в директории <tt>./views</tt>.
-Чтобы использовать другую директорию с шаблонами:
-  set :views, settings.root + '/templates'
-Важное замечание: вы всегда должны ссылаться на шаблоны с помощью символов
-(Symbol), даже когда они в поддиректории (в этом случае используйте
-<tt>:'subdir/template'</tt>). Вы должны использовать символы, потому что
-иначе шаблонизаторы попросту отображают любые строки, переданные им.
-=== Доступные шаблонизаторы
-Некоторые языки шаблонов имеют несколько реализаций. Чтобы указать, какую
-реализацию использовать, вам следует просто подключить нужную
-библиотеку:
-  require 'rdiscount' # или require 'bluecloth'
-  get('/') { markdown :index }
-=== Haml шаблоны
-Зависимости::         {haml}[http://haml.info/]
-Расширения файлов::   <tt>.haml</tt>
-Пример::              <tt>haml :index, :format => :html5</tt>
-=== Erb шаблоны
-Зависимости::         {erubis}[http://www.kuwata-lab.com/erubis/] или erb (включен в Ruby)
-Расширения файлов::   <tt>.erb</tt>, <tt>.rhtml</tt> or <tt>.erubis</tt> (только Erubis)
-Пример::              <tt>erb :index</tt>
-=== Builder шаблоны
-Зависимости::         {builder}[http://builder.rubyforge.org/]
-Расширения файлов::   <tt>.builder</tt>
-Пример::              <tt>builder { |xml| xml.em "hi" }</tt>
-Блок также используется и для встроенных шаблонов (см. пример).
-=== Nokogiri шаблоны
-Зависимости::         {nokogiri}[http://nokogiri.org/]
-Расширения файлов::   <tt>.nokogiri</tt>
-Пример::              <tt>nokogiri { |xml| xml.em "hi" }</tt>
-Блок также используется и для встроенных шаблонов (см. пример).
-=== Sass шаблоны
-Зависимости::         {sass}[http://sass-lang.com/]
-Расширения файлов::   <tt>.sass</tt>
-Пример::              <tt>sass :stylesheet, :style => :expanded</tt>
-=== SCSS шаблоны
-Зависимости::         {sass}[http://sass-lang.com/]
-Расширения файлов::   <tt>.scss</tt>
-Пример::              <tt>scss :stylesheet, :style => :expanded</tt>
-=== Less шаблоны
-Зависимости::         {less}[http://www.lesscss.org/]
-Расширения файлов::   <tt>.less</tt>
-Пример::              <tt>less :stylesheet</tt>
-=== Liquid шаблоны
-Зависимости::         {liquid}[http://www.liquidmarkup.org/]
-Расширения файлов::   <tt>.liquid</tt>
-Пример::              <tt>liquid :index, :locals => { :key => 'value' }</tt>
-Так как в Liquid шаблонах невозможно вызывать методы из Ruby (кроме yield), то
-вы почти всегда будете передавать в шаблон локальные переменные.
-=== Markdown шаблоны
-Зависимости::          {rdiscount}[https://github.com/rtomayko/rdiscount], {redcarpet}[https://github.com/tanoku/redcarpet], {bluecloth}[http://deveiate.org/projects/BlueCloth], {kramdown}[http://kramdown.rubyforge.org/] или {maruku}[http://maruku.rubyforge.org/]
-Расширения файлов::   <tt>.markdown</tt>, <tt>.mkd</tt> and <tt>.md</tt>
-Пример::              <tt>markdown :index, :layout_engine => :erb</tt>
-В Markdown невозможно вызывать методы или передавать локальные переменные.
-Следовательно, вам, скорее всего, придется использовать этот шаблон совместно
-с другим шаблонизатором:
-  erb :overview, :locals => { :text => markdown(:introduction) }
-Заметьте, что вы можете вызывать метод +markdown+ из других шаблонов:
-  %h1 Hello From Haml!
-  %p= markdown(:greetings)
-Вы не можете вызывать Ruby из Markdown, соответственно, вы не можете
-использовать лэйауты на Markdown. Тем не менее, есть возможность использовать
-один шаблонизатор для отображения шаблона, а другой для лэйаута с помощью
-опции <tt>:layout_engine</tt>.
-=== Textile шаблоны
-Зависимости::         {RedCloth}[http://redcloth.org/]
-Расширения файлов::   <tt>.textile</tt>
-Пример::              <tt>textile :index, :layout_engine => :erb</tt>
-В Textile невозможно вызывать методы или передавать локальные переменные.
-Следовательно, вам, скорее всего, придется использовать этот шаблон совместно с
-другим шаблонизатором:
-  erb :overview, :locals => { :text => textile(:introduction) }
-Заметьте, что вы можете вызывать метод +textile+ из других шаблонов:
-  %h1 Hello From Haml!
-  %p= textile(:greetings)
-Вы не можете вызывать Ruby из Textile, соответственно, вы не можете
-использовать лэйауты на Textile. Тем не менее, есть возможность использовать
-один шаблонизатор для отображения шаблона, а другой для лэйаута с помощью
-опции <tt>:layout_engine</tt>.
-=== RDoc шаблоны
-Зависимости::         {rdoc}[http://rdoc.rubyforge.org/]
-Расширения файлов::   <tt>.rdoc</tt>
-Пример::              <tt>textile :README, :layout_engine => :erb</tt>
-В RDoc невозможно вызывать методы или передавать локальные переменные.
-Следовательно, вам, скорее всего, придется использовать этот шаблон совместно с
-другим шаблонизатором:
-  erb :overview, :locals => { :text => rdoc(:introduction) }
-Заметьте, что вы можете вызывать метод +rdoc+ из других шаблонов:
-  %h1 Hello From Haml!
-  %p= rdoc(:greetings)
-Вы не можете вызывать Ruby из RDoc, соответственно, вы не можете
-использовать лэйауты на RDoc. Тем не менее, есть возможность использовать
-один шаблонизатор для отображения шаблона, а другой для лэйаута с помощью
-опции <tt>:layout_engine</tt>.
-=== Radius шаблоны
-Зависимости::         {radius}[http://radius.rubyforge.org/]
-Расширения файлов::   <tt>.radius</tt>
-Пример::              <tt>radius :index, :locals => { :key => 'value' }</tt>
-Так как в Radius шаблонах невозможно вызывать методы из Ruby напрямую, то
-вы почти всегда будете передавать в шаблон локальные переменные.
-=== Markaby шаблоны
-Зависимости::         {markaby}[http://markaby.github.com/]
-Расширения файлов::   <tt>.mab</tt>
-Пример::              <tt>markaby { h1 "Welcome!" }</tt>
-Блок также используется и для встроенных шаблонов (см. пример).
-=== Slim шаблоны
-Зависимости::         {slim}[http://slim-lang.com/]
-Расширения файлов::   <tt>.slim</tt>
-Пример::              <tt>slim :index</tt>
-=== Creole шаблоны
-Зависимости::         {creole}[https://github.com/minad/creole]
-Расширения файлов::   <tt>.creole</tt>
-Пример::              <tt>creole :wiki, :layout_engine => :erb</tt>
-В Creole невозможно вызывать методы или передавать локальные переменные.
-Следовательно, вам, скорее всего, придется использовать этот шаблон совместно с
-другим шаблонизатором:
-  erb :overview, :locals => { :text => creole(:introduction) }
-Заметьте, что вы можете вызывать метод +creole+ из других шаблонов:
-  %h1 Hello From Haml!
-  %p= creole(:greetings)
-Вы не можете вызывать Ruby из Creole, соответственно, вы не можете
-использовать лэйауты на Creole. Тем не менее, есть возможность использовать
-один шаблонизатор для отображения шаблона, а другой для лэйаута с помощью
-опции <tt>:layout_engine</tt>.
-=== CoffeeScript шаблоны
-Зависимости::         {coffee-script}[https://github.com/josh/ruby-coffee-script] и {способ запускать javascript}[https://github.com/sstephenson/execjs/blob/master/README.md#readme]
-Расширения файлов::   <tt>.coffee</tt>
-Пример::              <tt>coffee :index</tt>
-=== Встроенные шаблоны
-  get '/' do
-    haml '%div.title Hello World'
-  end
-Отобразит встроенный шаблон, переданный строкой.
-=== Доступ к переменным в шаблонах
-Шаблоны интерпретируются в том же контексте, что и обработчики маршрутов. Переменные экземпляра,
-установленные в процессе обработки маршрутов, будут доступны напрямую в шаблонах:
-  get '/:id' do
-    @foo = Foo.find(params[:id])
-    haml '%h1= @foo.name'
-  end
-Либо установите их через хеш локальных переменных:
-  get '/:id' do
-    foo = Foo.find(params[:id])
-    haml '%h1= bar.name', :locals => { :bar => foo }
-  end
-Это обычный подход, когда шаблоны рендерятся как части других шаблонов.
-=== Вложенные шаблоны
-Шаблоны также могут быть определены в конце исходного файла:
-  require 'sinatra'
-  get '/' do
-    haml :index
-  end
-  __END__
-  @@ layout
-  %html
-    = yield
-  @@ index
-  %div.title Hello world!!!!!
-Заметьте: вложенные шаблоны, определенные в исходном файле, который подключила Sinatra, будут
-автоматически загружены. Вызовите <tt>enable :inline_templates</tt> напрямую, если у вас вложенные
-шаблоны в других файлах.
-=== Именные шаблоны
-Шаблоны также могут быть определены при помощи <tt>template</tt> метода:
-  template :layout do
-    "%html\n  =yield\n"
-  end
-  template :index do
-    '%div.title Hello World!'
-  end
-  get '/' do
-    haml :index
-  end
-Если шаблон с именем "layout" существует, то он будет использоваться каждый раз
-при рендеринге. Вы можете отключать лэйаут в каждом конкретном случае с помощью
-<tt>:layout => false</tt> или отключить его для всего приложения, например, так:
-<tt>set :haml, :layout => false</tt>:
-  get '/' do
-    haml :index, :layout => !request.xhr?
-  end
-=== Привязка файловых расширений
-Чтобы связать расширение файла с движком рендеринга, используйте
-<tt>Tilt.register</tt>. Например, если вы хотите использовать расширение +tt+
-для шаблонов Textile:
-  Tilt.register :tt, Tilt[:textile]
-=== Добавление собственного движка рендеринга
-Сначала зарегистрируйте свой движок в Tilt, затем создайте метод, отвечающий за отрисовку:
-  Tilt.register :myat, MyAwesomeTemplateEngine
-  helpers do
-    def myat(*args) render(:myat, *args) end
-  end
-  get '/' do
-    myat :index
-  end
-Отобразит <tt>./views/index.myat</tt>. Чтобы узнать больше о Tilt,
-смотрите https://github.com/rtomayko/tilt
-== Фильтры
-+before+-фильтры выполняются перед каждым запросом в том же контексте, что и маршруты. Фильтры могут изменять
-как запрос, так и ответ на него. Переменные экземпляра, установленные в фильтрах, доступны в маршрутах и шаблонах:
-  before do
-    @note = 'Hi!'
-    request.path_info = '/foo/bar/baz'
-  end
-  get '/foo/*' do
-    @note #=> 'Hi!'
-    params[:splat] #=> 'bar/baz'
-  end
-+after+-фильтры выполняются после каждого запроса в том же контексте, что и пути. Фильтры могут изменять
-как запрос, так и ответ на него. Переменные экземпляра, установленные в +before+-фильтрах и маршрутах,
-будут доступны в +after+-фильтрах:
-  after do
-    puts response.status
-  end
-Заметьте: если вы используете метод +body+, а не просто возвращаете строку из
-маршрута, то тело ответа не будет доступно в +after+-фильтрах, так как оно будет сгенерировано позднее.
-Фильтры могут использовать шаблоны URL и будут интерпретированы только если путь запроса совпадет с этим шаблоном:
-  before '/protected/*' do
-    authenticate!
-  end
-  after '/create/:slug' do |slug|
-    session[:last_slug] = slug
-  end
-Как и маршруты, фильтры могут использовать условия:
-  before :agent => /Songbird/ do
-    # ...
-  end
-  after '/blog/*', :host_name => 'example.com' do
-    # ...
-  end
-== Методы-помощники
-Используйте метод <tt>helpers</tt>, чтобы определить методы-помощники, которые
-в дальнейшем можно будет использовать в обработчиках маршрутов и шаблонах:
-  helpers do
-    def bar(name)
-      "#{name}bar"
-    end
-  end
-  get '/:name' do
-    bar(params[:name])
-  end
-=== Использование сессий
-Сессия используется, чтобы сохранять состояние между запросами. Если эта опция
-включена, то у вас будет один хеш сессии на одну пользовательскую сессию:
-  enable :sessions
-  get '/' do
-    "value = " << session[:value].inspect
-  end
-  get '/:value' do
-    session[:value] = params[:value]
-  end
-Заметьте, что при использовании <tt>enable :sessions</tt> все данные
-сохраняются в cookies. Это может быть не совсем то, что вы хотите (например,
-сохранение больших объемов данных увеличит ваш трафик). В таком случае вы
-можете использовать альтернативную Rack "прослойку" (middleware), реализующую
-механизм сессий. Для этого *не надо* вызывать <tt>enable :sessions</tt>,
-вместо этого следует подключить ее так же, как и любую другую "прослойку":
-  use Rack::Session::Pool, :expire_after => 2592000
-  get '/' do
-    "value = " << session[:value].inspect
-  end
-  get '/:value' do
-    session[:value] = params[:value]
-  end
-Для повышения безопасности данные сессии в куках подписываются секретным
-ключом. Секретный ключ генерируется Sinatra. Тем не менее, так как этот
-ключ будет меняться с каждым запуском приложения, вы, возможно, захотите
-установить ключ вручную, чтобы у всех экземпляров вашего приложения
-был один и тот же ключ:
-  set :session_secret, 'super secret'
-Если вы хотите больше настроек для сессий, вы можете задать их, передав хеш опций в параметр +sessions+:
-  set :sessions, :domain => 'foo.com'
-=== Прерывание
-Чтобы незамедлительно прервать обработку запроса внутри фильтра или маршрута, используйте:
-  halt
-Можно также указать статус при прерывании:
-  halt 410
-Тело:
-  halt 'this will be the body'
-И то, и другое:
-  halt 401, 'go away!'
-Можно указать заголовки:
-  halt 402, {'Content-Type' => 'text/plain'}, 'revenge'
-И, конечно, можно использовать шаблоны с +halt+:
-  halt erb(:error)
-=== Передача
-Маршрут может передать обработку запроса следующему совпадающему маршруту, используя <tt>pass</tt>:
-  get '/guess/:who' do
-    pass unless params[:who] == 'Frank'
-    'You got me!'
-  end
-  get '/guess/*' do
-    'You missed!'
-  end
-Блок маршрута сразу же прерывается, и контроль переходит к следующему совпадающему маршруту.
-Если соответствующий маршрут не найден, то ответом на запрос будет 404.
-=== Вызов другого маршрута
-Иногда +pass+ не подходит, например, если вы хотите получить результат
-вызова другого обработчика маршрута. В таком случае просто используйте +call+:
-  get '/foo' do
-    status, headers, body = call env.merge("PATH_INFO" => '/bar')
-    [status, headers, body.map(&:upcase)]
-  end
-  get '/bar' do
-    "bar"
-  end
-Заметьте, что в предыдущем примере можно облегчить тестирование и повысить
-производительность, перенеся <tt>"bar"</tt> в метод-помощник, используемый
-и в <tt>/foo</tt>, и в <tt>/bar</tt>.
-Если вы хотите, чтобы запрос был отправлен в тот же экземпляр приложения, а не
-в его копию, используйте <tt>call!</tt> вместо <tt>call</tt>.
-Если хотите узнать больше о <tt>call</tt>, смотрите спецификацию Rack.
-=== Задание тела, кода и заголовков ответа
-Хорошим тоном является установка кода состояния HTTP и тела ответа в возвращаемом
-значении обработчика маршрута. Тем не менее, в некоторых ситуациях вам, возможно,
-понадобится задать тело ответа в произвольной точке потока исполнения. Вы можете
-сделать это с помощью метода-помощника +body+. Если вы задействуете метод +body+,
-то вы можете использовать его и в дальнейшем, чтобы получить доступ к телу ответа.
-  get '/foo' do
-    body "bar"
-  end
-  after do
-    puts body
-  end
-Также можно передать блок в метод +body+, который затем будет вызван
-обработчиком Rack (такой подход может быть использован для реализации поточного
-ответа, см. "Возвращаемые значения").
-Аналогично вы можете установить код ответа и его заголовки:
-  get '/foo' do
-    status 418
-    headers \
-      "Allow"   => "BREW, POST, GET, PROPFIND, WHEN",
-      "Refresh" => "Refresh: 20; http://www.ietf.org/rfc/rfc2324.txt"
-    body "I'm a tea pot!"
-  end
-Как и +body+, методы +headers+ и +status+, вызванные без аргументов, возвращают
-свои текущие значения.
-=== Логирование
-В области видимости запроса метод +logger+ предоставляет доступ к экземпляру +Logger+:
-  get '/' do
-    logger.info "loading data"
-    # ...
-  end
-Этот логер автоматически учитывает ваши настройки логирования в Rack. Если
-логирование выключено, то этот метод вернет пустой (dummy) объект, поэтому вы можете
-смело использовать его в маршрутах и фильтрах.
-Заметьте, что логирование включено по умолчанию только для <tt>Sinatra::Application</tt>,
-а если ваше приложение -- подкласс <tt>Sinatra::Base</tt>, то вы, наверное, захотите включить
-его вручную:
-  class MyApp < Sinatra::Base
-    configure(:production, :development) do
-      enable :logging
-    end
-  end
-=== Mime-типы
-Когда вы используете <tt>send_file</tt> или статические файлы, у вас могут быть mime-типы, которые Sinatra
-не понимает по умолчанию. Используйте +mime_type+ для их регистрации по расширению файла:
-  configure do
-    mime_type :foo, 'text/foo'
-  end
-Вы также можете использовать это в +content_type+ методе-помощнике:
-  get '/' do
-    content_type :foo
-    "foo foo foo"
-  end
-=== Генерирование URL
-Чтобы сформировать URL вам следует использовать метод +url+, например, в Haml:
-  %a{:href => url('/foo')} foo
-Этот метод учитывает обратные прокси и маршрутизаторы Rack, если они присутствуют.
-Наряду с +url+ вы можете использовать +to+ (смотрите пример ниже).
-=== Перенаправление (редирект)
-Вы можете перенаправить браузер пользователя с помощью метода +redirect+:
-  get '/foo' do
-    redirect to('/bar')
-  end
-Любые дополнительные параметры используются по аналогии с аргументами метода +halt+:
-  redirect to('/bar'), 303
-  redirect 'http://google.com', 'wrong place, buddy'
-Вы также можете перенаправить пользователя обратно, на страницу с которой он пришел,
-с помощью <tt>redirect back</tt>:
-  get '/foo' do
-    "<a href='/bar'>do something</a>"
-  end
-  get '/bar' do
-    do_something
-    redirect back
-  end
-Чтобы передать какие-либо параметры вместе с перенаправлением, либо добавьте их в строку запроса:
-  redirect to('/bar?sum=42')
-либо используйте сессию:
-  enable :sessions
-  get '/foo' do
-    session[:secret] = 'foo'
-    redirect to('/bar')
-  end
-  get '/bar' do
-    session[:secret]
-  end
-=== Управление кэшированием
-Установка корректных заголовков — основа правильного HTTP кэширования.
-Вы можете легко выставить заголовок Cache-Control таким образом:
-  get '/' do
-    cache_control :public
-    "cache it!"
-  end
-Совет: задавайте кэширование в +before+-фильтре:
-  before do
-    cache_control :public, :must_revalidate, :max_age => 60
-  end
-Если вы используете метод +expires+ для задания соответствующего заголовка,
-то <tt>Cache-Control</tt> будет выставлен автоматически:
-  before do
-    expires 500, :public, :must_revalidate
-  end
-Чтобы как следует использовать кэширование, вам следует подумать об использовании
-+etag+ и +last_modified+. Рекомендуется использовать эти методы-помощники *до*
-выполнения ресурсоемких вычислений, так как они немедленно отправят ответ клиенту,
-если текущая версия уже есть в их кэше:
-  get '/article/:id' do
-    @article = Article.find params[:id]
-    last_modified @article.updated_at
-    etag @article.sha1
-    erb :article
-  end
-Также вы можете использовать
-{weak ETag}[http://en.wikipedia.org/wiki/HTTP_ETag#Strong_and_weak_validation]:
-  etag @article.sha1, :weak
-Эти методы-помощники не станут ничего кэшировать для вас, но они дадут
-необходимую информацию для вашего кэша. Если вы ищите легкое решение для
-кэширования, попробуйте {rack-cache}[http://rtomayko.github.com/rack-cache/]:
-  require 'rack/cache'
-  require 'sinatra'
-  use Rack::Cache
-  get '/' do
-    cache_control :public, :max_age => 36000
-    sleep 5
-    "hello"
-  end
-Используйте опцию <tt>:static_cache_control</tt> (см. ниже), чтобы
-добавить заголовок <tt>Cache-Control</tt> к статическим файлам.
-=== Отправка файлов
-Для отправки файлов пользователю вы можете использовать метод <tt>send_file</tt>:
-  get '/' do
-    send_file 'foo.png'
-  end
-Этот метод имеет несколько опций:
-  send_file 'foo.png', :type => :jpg
-Возможные опции:
-[filename]
-  имя файла, по умолчанию: реальное имя файла.
-[last_modified]
-  значение для заголовка Last-Modified, по умолчанию: mtime (время изменения) файла.
-[type]
-  тип файла, по умолчанию: предполагается по расширению файла.
-[disposition]
-  используется для заголовка Content-Disposition, возможные значения:
-  +nil+ (по умолчанию), <tt>:attachment</tt> и <tt>:inline</tt>.
-[length]
-  значения для заголовка Content-Length, по умолчанию: размер файла.
-Этот метод будет использовать возможности Rack сервера для отправки файлов, если они
-доступны, а в противном случае, будет напрямую отдавать файл из Ruby процесса.
-Метод <tt>send_file</tt> также обеспечивает автоматическую обработку частичных (range)
-запросов с помощью Sinatra.
-=== Доступ к объекту запроса
-Объект входящего запроса доступен на уровне обработки запроса (в фильтрах, маршрутах,
-обработчиках ошибок) с помощью <tt>request</tt> метода:
-  # приложение запущено на http://example.com/example
-  get '/foo' do
-    t = %w[text/css text/html application/javascript]
-    request.accept              # ['text/html', '*/*']
-    request.accept? 'text/xml'  # true
-    request.preferred_type(t)   # 'text/html'
-    request.body                # тело запроса, посланное клиентом (см. ниже)
-    request.scheme              # "http"
-    request.script_name         # "/example"
-    request.path_info           # "/foo"
-    request.port                # 80
-    request.request_method      # "GET"
-    request.query_string        # ""
-    request.content_length      # длина тела запроса
-    request.media_type          # медиатип тела запроса
-    request.host                # "example.com"
-    request.get?                # true (есть аналоги для других методов HTTP)
-    request.form_data?          # false
-    request["some_param"]       # значение параметра some_param. Шорткат для хеша params
-    request.referrer            # источник запроса клиента либо '/'
-    request.user_agent          # user agent (используется для :agent условия)
-    request.cookies             # хеш, содержащий cookies браузера
-    request.xhr?                # является ли запрос ajax запросом?
-    request.url                 # "http://example.com/example/foo"
-    request.path                # "/example/foo"
-    request.ip                  # IP-адрес клиента
-    request.secure?             # false (true, если запрос сделан через SSL)
-    request.forwarded?          # true (если сервер работает за обратным прокси)
-    request.env                 # "сырой" env хеш, полученный Rack
-  end
-Некоторые опции, такие как <tt>script_name</tt> или <tt>path_info</tt> доступны для изменения:
-  before { request.path_info = "/" }
-  get "/" do
-    "all requests end up here"
-  end
-<tt>request.body</tt> является IO или StringIO объектом:
-  post "/api" do
-    request.body.rewind  # в случае, если кто-то уже прочитал тело запроса
-    data = JSON.parse request.body.read
-    "Hello #{data['name']}!"
-  end
-=== Вложения
-Вы можете использовать метод +attachment+, чтобы сказать браузеру, что ответ
-сервера должен быть сохранен на диск, а не отображен:
-  get '/' do
-    attachment
-    "store it!"
-  end
-Вы также можете указать имя файла:
-  get '/' do
-    attachment "info.txt"
-    "store it!"
-  end
-=== Поиск шаблонов
-Для поиска шаблонов и их последующего рендеринга используется метод <tt>find_template</tt>:
-  find_template settings.views, 'foo', Tilt[:haml] do |file|
-    puts "could be #{file}"
-  end
-Это не слишком полезный пример. Зато полезен тот факт, что вы можете переопределить
-этот метод, чтобы использовать свой собственный механизм поиска. Например, если вы
-хотите, чтобы можно было использовать несколько директорий с шаблонами:
-  set :views, ['views', 'templates']
-  helpers do
-    def find_template(views, name, engine, &block)
-      Array(views).each { |v| super(v, name, engine, &block) }
-    end
-  end
-Другой пример, в котором используются разные директории для движков рендеринга:
-  set :views, :sass => 'views/sass', :haml => 'templates', :default => 'views'
-  helpers do
-    def find_template(views, name, engine, &block)
-      _, folder = views.detect { |k,v| engine == Tilt[k] }
-      folder ||= views[:default]
-      super(folder, name, engine, &block)
-    end
-  end
-Вы можете легко вынести этот код в расширение и поделиться им с остальными!
-Заметьте, что <tt>find_template</tt> не проверяет, существует ли файл на самом деле,
-а вызывает заданный блок для всех возможных путей. Дело тут не в производительности,
-дело в том, что +render+ вызовет +break+, как только файл не будет найден.
-Содержимое и местонахождение шаблонов будет закэшировано, если приложение запущено не
-в режиме разработки (set :environment, :development). Вы должны помнить об этих нюансах,
-если пишите по-настоящему "сумасшедший" метод.
-== Конфигурация
-Этот блок исполняется один раз при старте в любом окружении, режиме (environment):
-  configure do
-    # задание одной опции
-    set :option, 'value'
-    # устанавливаем несколько опций
-    set :a => 1, :b => 2
-    # то же самое, что и `set :option, true`
-    enable :option
-    # то же самое, что и `set :option, false`
-    disable :option
-    # у вас могут быть "динамические" опции с блоками
-    set(:css_dir) { File.join(views, 'css') }
-  end
-Будет запущено, когда окружение (RACK_ENV переменная) <tt>:production</tt>:
-  configure :production do
-    ...
-  end
-Будет запущено, когда окружение <tt>:production</tt> или <tt>:test</tt>:
-  configure :production, :test do
-    ...
-  end
-Вы можете получить доступ к этим опциям с помощью <tt>settings</tt>:
-  configure do
-    set :foo, 'bar'
-  end
-  get '/' do
-    settings.foo? # => true
-    settings.foo  # => 'bar'
-    ...
-  end
-=== Доступные настройки
-[absolute_redirects]   если отключено, то Sinatra будет позволять использование
-                       относительных перенаправлений, но при этом перестанет
-                       соответствовать RFC 2616 (HTTP 1.1), который разрешает только
-                       абсолютные перенаправления.
-                       Включайте эту опцию, если ваше приложение работает за обратным прокси,
-                       который настроен не совсем корректно. Обратите внимание, метод +url+
-                       все равно будет генерировать абсолютные URL, если вы не передадите
-                       +false+ вторым аргументом.
-                       Отключено по умолчанию.
-[add_charsets]         mime-типы, к которым метод <tt>content_type</tt> будет автоматически
-                       добавлять информацию о кодировке.
-                       Вам следует добавлять значения к этой опции вместо ее переопределения:
-                         settings.add_charsets << "application/foobar"
-[app_file]             главный файл приложения, используется для определения корневой директории
-                       проекта, директорий с шаблонами и статическими файлами, вложенных шаблонов.
-[bind]                 используемый IP-адрес (по умолчанию: 0.0.0.0). Используется только
-                       встроенным сервером.
-[default_encoding]     кодировка, если неизвестна (по умолчанию: <tt>"utf-8"</tt>).
-[dump_errors]          отображать ошибки в логе.
-[environment]          текущее окружение, по умолчанию, значение <tt>ENV['RACK_ENV']</tt>
-                       или <tt>"development"</tt>, если <tt>ENV['RACK_ENV']</tt> не доступна.
-[logging]              использовать логер.
-[lock]                 создает блокировку для каждого запроса, которая гарантирует обработку
-                       только одного запроса в текущий момент времени в Ruby процессе.
-                       Включайте, если ваше приложение не потоко-безопасно (thread-safe).
-                       Отключено по умолчанию.
-[method_override]      использовать "магический" параметр <tt>_method</tt>, чтобы позволить
-                       использование PUT/DELETE форм в браузерах, которые не поддерживают
-                       эти методы.
-[port]                 порт, на котором будет работать сервер. Используется только
-                       встроенным сервером.
-[prefixed_redirects]   добавлять или нет параметр <tt>request.script_name</tt> к редиректам,
-                       если не задан абсолютный путь. Таким образом,  <tt>redirect '/foo'</tt>
-                       будет вести себя как <tt>redirect to('/foo')</tt>. Отключено по умолчанию.
-[public_folder]        директория, откуда будут раздаваться статические файлы.
-[reload_templates]     перезагружать или нет шаблоны на каждый запрос.
-                       Включено в режиме разработки.
-[root]                 корневая директория проекта.
-[raise_errors]         выбрасывать исключения (будет останавливать приложение).
-[run]                  если включено, Sinatra будет самостоятельно запускать веб-сервер.
-                       Не включайте, если используете rackup или аналогичные средства.
-[running]              работает ли сейчас встроенный сервер?
-                       Не меняйте эту опцию!
-[server]               сервер или список серверов, которые следует использовать в качестве
-                       встроенного сервера. По умолчанию: ['thin', 'mongrel', 'webrick'],
-                       порядок задает приоритет.
-[sessions]             включить сессии на основе кук (cookie).
-[show_exceptions]      показывать исключения/стек вызовов (stack trace) в браузере.
-[static]               должна ли Sinatra осуществлять раздачу статических файлов.
-                       Отключите, когда используете какой-либо веб-сервер для этой цели.
-                       Отключение значительно улучшит производительность приложения.
-                       По умолчанию включено в классических и отключено в модульных
-                       приложениях.
-[static_cache_control] Когда Sinatra отдает статические файлы, используйте эту опцию,
-                       чтобы добавить им заголовок <tt>Cache-Control</tt>. Для этого
-                       используется метод-помощник +cache_control+. По умолчанию отключено.
-                       Используйте массив, когда надо задать несколько значений:
-                       <tt>set :static_cache_control, [:public, :max_age => 300]</tt>
-[views]               директория с шаблонами.
-== Обработка ошибок
-Обработчики ошибок исполняются в том же контексте, что и маршруты, и +before+-фильтры, а это означает, что всякие
-прелести вроде <tt>haml</tt>, <tt>erb</tt>, <tt>halt</tt> и т.д. доступны и им.
-=== Not Found
-Когда выброшено исключение <tt>Sinatra::NotFound</tt>, или кодом ответа является 404,
-то будет вызван <tt>not_found</tt> обработчик:
-  not_found do
-    'This is nowhere to be found.'
-  end
-=== Ошибки
-Обработчик ошибок +error+ будет вызван, когда исключение выброшено из блока маршрута, либо из фильтра.
-Объект-исключение доступен как переменная <tt>sinatra.error</tt> в Rack:
-  error do
-    'Sorry there was a nasty error - ' + env['sinatra.error'].name
-  end
-Частные ошибки:
-  error MyCustomError do
-    'So what happened was...' + env['sinatra.error'].message
-  end
-Тогда, если это произошло:
-  get '/' do
-    raise MyCustomError, 'something bad'
-  end
-То вы получите:
-  So what happened was... something bad
-Также вы можете установить обработчик ошибок для кода состояния HTTP:
-  error 403 do
-    'Access forbidden'
-  end
-  get '/secret' do
-    403
-  end
-Либо набора кодов:
-  error 400..510 do
-    'Boom'
-  end
-Sinatra устанавливает специальные <tt>not_found</tt> и <tt>error</tt> обработчики, когда приложение запущено в режиме
-разработки (окружение <tt>:development</tt>).
-== Rack "прослойки"
-Sinatra использует Rack[http://rack.rubyforge.org/], минимальный стандартный
-интерфейс для веб-фреймворков на Ruby. Одной из самых интересных для разработчиков возможностей Rack
-является поддержка "прослоек" ("middleware") — компонентов,
-находящихся "между" сервером и вашим приложением, которые отслеживают и/или манипулируют
-HTTP запросами/ответами для предоставления различной функциональности.
-В Sinatra очень просто использовать такие "прослойки" с помощью метода +use+:
-  require 'sinatra'
-  require 'my_custom_middleware'
-  use Rack::Lint
-  use MyCustomMiddleware
-  get '/hello' do
-    'Hello World'
-  end
-Семантика +use+ идентична той, что определена для
-Rack::Builder[http://rack.rubyforge.org/doc/classes/Rack/Builder.html] DSL
-(чаще всего используется в rackup файлах). Например, метод +use+ принимает
-как множественные переменные, так и блоки:
-  use Rack::Auth::Basic do |username, password|
-    username == 'admin' && password == 'secret'
-  end
-Rack распространяется с различными стандартными "прослойками"
-для логирования, отладки, маршрутизации URL, аутентификации, обработки сессий. Sinatra использует
-многие из этих компонентов автоматически, основываясь на конфигурации, чтобы вам не приходилось
-подключать (+use+) их вручную.
-Вы можете найти полезные прослойки в
-{rack}[https://github.com/rack/rack/tree/master/lib/rack],
-{rack-contrib}[https://github.com/rack/rack-contrib#readme],
-{CodeRack}[http://coderack.org/] или в
-{Rack wiki}[https://github.com/rack/rack/wiki/List-of-Middleware].
-== Тестирование
-Тесты для Sinatra приложений могут быть написаны с помощью библиотек, фреймворков, поддерживающих
-тестирование Rack. {Rack::Test}[http://rdoc.info/github/brynary/rack-test/master/frames] рекомендован:
-  require 'my_sinatra_app'
-  require 'test/unit'
-  require 'rack/test'
-  class MyAppTest < Test::Unit::TestCase
-    include Rack::Test::Methods
-    def app
-      Sinatra::Application
-    end
-    def test_my_default
-      get '/'
-      assert_equal 'Hello World!', last_response.body
-    end
-    def test_with_params
-      get '/meet', :name => 'Frank'
-      assert_equal 'Hello Frank!', last_response.body
-    end
-    def test_with_rack_env
-      get '/', {}, 'HTTP_USER_AGENT' => 'Songbird'
-      assert_equal "You're using Songbird!", last_response.body
-    end
-  end
-== Sinatra::Base — "прослойки", библиотеки и модульные приложения
-Описание своего приложения самым простейшим способом (с помощью DSL верхнего уровня,
-как в примерах выше) отлично работает для крохотных приложений. Тем не менее,
-такой метод имеет множество недостатков при создании компонентов, таких как
-Rack middleware ("прослоек"), Rails metal, простых библиотек с серверными компонентами,
-расширений Sinatra.
-DSL верхнего уровня "загрязняет" пространство имен <tt>Object</tt> и подразумевает стиль конфигурации
-микро-приложения (например, единый файл приложения, <tt>./public</tt> и
-<tt>./views</tt> директории, логирование, страницу деталей об исключениях
-и т.д.). И тут на помощь приходит <tt>Sinatra::Base</tt>:
-  require 'sinatra/base'
-  class MyApp < Sinatra::Base
-    set :sessions, true
-    set :foo, 'bar'
-    get '/' do
-      'Hello world!'
-    end
-  end
-Методы, доступные <tt>Sinatra::Base</tt> подклассам идентичны тем, что доступны
-в DSL верхнего уровня. Большинство приложений верхнего уровня могут быть
-конвертированы в <tt>Sinatra::Base</tt> компоненты с помощью двух модификаций:
-* Вы должны подключать <tt>sinatra/base</tt> вместо +sinatra+,
-  иначе все методы, предоставляемые Sinatra, будут импортированы в глобальное пространство имен.
-* Поместите все маршруты, обработчики ошибок, фильтры и опции в подкласс <tt>Sinatra::Base</tt>.
-<tt>Sinatra::Base</tt> — это чистый лист. Большинство опций, включая встроенный сервер, по умолчанию отключены.
-Смотрите {Опции и конфигурация}[http://www.sinatrarb.com/configuration.html] для детальной информации
-об опциях и их поведении.
-=== Модульные приложения против классических
-Вопреки всеобщему убеждению, в классическом стиле (самом простом) нет ничего плохого.
-Если этот стиль подходит вашему приложению, вы не обязаны переписывать его в модульное
-приложение.
-У классического стиля есть всего два недостатка относительно модульного:
-* У вас может быть только одно приложение Sinatra на один Ruby процесс. Если вы планируете
-  использовать больше, то переключайтесь на модульный стиль.
-* Приложения, использующие классический стиль, добавляют методы к Object. Если вы
-  планируете поставлять свое приложение в виде библиотеки/gem, то переходите
-  на модульный стиль.
-Не существует причин, по которым вы не могли бы смешивать модульный и классический стили.
-Переходя с одного стиля на другой, примите во внимание следующие изменения в настройках:
-  Опция               Классический            Модульный
-  app_file            файл с приложением      файл с подклассом Sinatra::Base
-  run                 $0 == app_file          false
-  logging             true                    false
-  method_override     true                    false
-  inline_templates    true                    false
-  static              true                    false
-=== Запуск модульных приложений
-Есть два общепринятых способа запускать модульные приложения: запуск напрямую с помощью <tt>run!</tt>:
-  # my_app.rb
-  require 'sinatra/base'
-  class MyApp < Sinatra::Base
-    # ... здесь код приложения ...
-    # запускаем сервер, если исполняется текущий файл
-    run! if app_file == $0
-  end
-И запускаем с помощью:
-  ruby my_app.rb
-Или с помощью конфигурационного файла <tt>config.ru</tt>, который позволяет использовать любой
-Rack-совместимый сервер приложений.
-  # config.ru
-  require './my_app'
-  run MyApp
-Запускаем:
-  rackup -p 4567
-=== Запуск классических приложений с config.ru
-Файл приложения:
-  # app.rb
-  require 'sinatra'
-  get '/' do
-    'Hello world!'
-  end
-И соответствующий <tt>config.ru</tt>:
-  require './app'
-  run Sinatra::Application
-=== Когда использовать config.ru?
-Вот несколько причин, по которым вы, возможно, захотите использовать <tt>config.ru</tt>:
-* вы хотите разворачивать свое приложение на различных Rack-совместимых серверах (Passenger, Unicorn,
-  Heroku, ...);
-* вы хотите использовать более одного подкласса <tt>Sinatra::Base</tt>;
-* вы хотите использовать Sinatra только в качестве "прослойки" Rack.
-<b>Совсем необязательно переходить на использование <tt>config.ru</tt> лишь потому, что вы стали
-использовать модульный стиль приложения. И необязательно использовать модульный стиль, чтобы
-запускать приложение с помощью <tt>config.ru</tt>.</b>
-=== Использование Sinatra в качестве "прослойки"
-Не только сама Sinatra может использовать "прослойки" Rack, но и любое Sinatra приложение
-само может быть добавлено к любому Rack endpoint в качестве "прослойки". Этим endpoint (конечной точкой)
-может быть другое Sinatra приложение, или приложение, основанное на Rack (Rails/Ramaze/Camping/...):
-  require 'sinatra/base'
-  class LoginScreen < Sinatra::Base
-    enable :sessions
-    get('/login') { haml :login }
-    post('/login') do
-      if params[:name] == 'admin' && params[:password] == 'admin'
-        session['user_name'] = params[:name]
-      else
-        redirect '/login'
-      end
-    end
-  end
-  class MyApp < Sinatra::Base
-    # "прослойка" будет запущена перед фильтрами
-    use LoginScreen
-    before do
-      unless session['user_name']
-        halt "Access denied, please <a href='/login'>login</a>."
-      end
-    end
-    get('/') { "Hello #{session['user_name']}." }
-  end
-=== Создание приложений "на лету"
-Иногда требуется создавать Sinatra приложения "на лету" (например,
-из другого приложения). Это возможно с помощью <tt>Sinatra.new</tt>:
-  require 'sinatra/base'
-  my_app = Sinatra.new { get('/') { "hi" } }
-  my_app.run!
-Этот метод может принимать аргументом приложение, от которого
-следует наследоваться:
-  # 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
-Это особенно полезно для тестирования расширений Sinatra и при
-использовании Sinatra внутри вашей библиотеки.
-Благодаря этому, использовать Sinatra как "прослойку" очень просто:
-  require 'sinatra/base'
-  use Sinatra do
-    get('/') { ... }
-  end
-  run RailsProject::Application
-== Области видимости и привязка
-Текущая область видимости определяет методы и переменные, доступные
-в данный момент.
-=== Область видимости приложения / класса
-Любое Sinatra приложение соответствует подклассу <tt>Sinatra::Base</tt>. Если вы
-используете DSL верхнего уровня (<tt>require 'sinatra'</tt>), то этим классом будет
-<tt>Sinatra::Application</tt>, иначе это будет подкласс, который вы создали вручную.
-На уровне класса вам будут доступны такие методы, как +get+ или +before+, но вы
-не сможете получить доступ к объектам +request+ или +session+, так как существует
-только один класс приложения для всех запросов.
-Опции, созданные с помощью +set+, являются методами уровня класса:
-    class MyApp < Sinatra::Base
-      # Я в области видимости приложения!
-      set :foo, 42
-      foo # => 42
-      get '/foo' do
-        # Я больше не в области видимости приложения!
-      end
-    end
-У вас будет область видимости приложения внутри:
-* тела вашего класса приложения;
-* методов, определенных расширениями;
-* блока, переданного в +helpers+;
-* блоков, использованных как значения для +set+;
-* блока, переданного в <tt>Sinatra.new</tt>.
-Вы можете получить доступ к объекту области видимости (классу приложения) следующими способами:
-* через объект, переданный блокам конфигурации (<tt>configure { |c| ... }</tt>);
-* +settings+ внутри области видимости запроса.
-=== Область видимости запроса/экземпляра
-Для каждого входящего запроса будет создан новый экземпляр вашего приложения,
-и все блоки обработчика будут запущены в этом контексте. В этой области
-видимости вам доступны +request+ и +session+ объекты, вызовы методов
-рендеринга, такие как +erb+ или +haml+. Вы можете получить доступ к
-области видимости приложения из контекста запроса, используя метод-помощник +settings+:
-  class MyApp < Sinatra::Base
-    # Я в области видимости приложения!
-    get '/define_route/:name' do
-      # Область видимости запроса '/define_route/:name'
-      @value = 42
-      settings.get("/#{params[:name]}") do
-        # Область видимости запроса "/#{params[:name]}"
-        @value # => nil (другой запрос)
-      end
-      "Route defined!"
-    end
-  end
-У вас будет область видимости запроса в:
-* get/head/post/put/delete/options блоках;
-* before/after фильтрах;
-* методах-помощниках;
-* шаблонах/отображениях.
-=== Область видимости делегирования
-Область видимости делегирования просто перенаправляет методы в область видимости класса.
-Однако, она не полностью ведет себя как область видимости класса, так как у вас нет
-привязки к классу. Только методы, явно помеченные для делегирования, будут доступны,
-а переменных/состояний области видимости класса не будет (иначе говоря,
-у вас будет другой +self+ объект). Вы можете
-непосредственно добавить методы делегирования, используя
-<tt>Sinatra::Delegator.delegate :method_name</tt>.
-У вас будет контекст делегирования внутри:
-* привязки верхнего уровня, если вы сделали <tt>require 'sinatra'</tt>;
-* объекта, расширенного с помощью <tt>Sinatra::Delegator</tt>.
-Посмотрите сами в код: тут
-{Sinatra::Delegator примесь}[http://github.com/sinatra/sinatra/blob/ceac46f0bc129a6e994a06100aa854f606fe5992/lib/sinatra/base.rb#L1128]
-будет {включена в глобальное пространство имен}[http://github.com/sinatra/sinatra/blob/ceac46f0bc129a6e994a06100aa854f606fe5992/lib/sinatra/main.rb#L28].
-== Командная строка
-Sinatra приложения могут быть запущены напрямую:
-  ruby myapp.rb [-h] [-x] [-e ENVIRONMENT] [-p PORT] [-o HOST] [-s HANDLER]
-Опции включают:
-  -h # раздел помощи
-  -p # указание порта (по умолчанию 4567)
-  -o # указание хоста (по умолчанию 0.0.0.0)
-  -e # указание окружения, режима (по умолчанию development)
-  -s # указание rack сервера/обработчика (по умолчанию thin)
-  -x # включить мьютекс-блокировку (по умолчанию выключена)
-== Системные требования
-Следующие версии Ruby официально поддерживаются:
-[ Ruby 1.8.7 ]
-  1.8.7 полностью поддерживается, тем не менее, если вас ничто не держит на
-  этой версии, рекомендуем обновиться до 1.9.2 или перейти на JRuby или Rubinius.
-[ Ruby 1.9.2 ]
-  1.9.2 поддерживается и рекомендована к использованию. Заметьте, что Radius и Markaby
-  пока несовместимы с 1.9.2. Не используйте 1.9.2p0, известно, что эта
-  версия весьма нестабильна при использовании Sinatra.
-[ Rubinius ]
-  Rubinius официально поддерживается (Rubinius >= 1.2.3), всё, включая все
-  языки шаблонов, работает.
-[ JRuby ]
-  JRuby официально поддерживается (JRuby >= 1.6.1). Нет никаких проблем с
-  использованием альтернативных шаблонов. Тем не менее, если вы выбираете
-  JRuby, то, пожалуйста, посмотрите на JRuby Rack-сервера, так как Thin не
-  поддерживается полностью на JRuby. Поддержка расширений на C в JRuby все
-  еще экспериментальная, что на данный момент затрагивает только RDiscount и
-  Redcarpet.
-<b>Ruby 1.8.6 больше не поддерживается.</b> Если вы хотите запускать свое
-приложение на 1.8.6, откатитесь до Sinatra 1.2, которая будет получать все
-исправления ошибок до тех пор, пока не будет выпущена Sinatra 1.4.0
-Мы также следим за предстоящими к выходу версиями Ruby.
-Следующие реализации Ruby не поддерживаются официально, но известно, что на
-них запускается Sinatra:
-* старые версии JRuby и Rubinius;
-* MacRuby, Maglev, IronRuby;
-* Ruby 1.9.0 и 1.9.1;
-* Ruby 1.8.6 с помощью {backports}[https://github.com/marcandre/backports/#readme].
-То, что версия официально не поддерживается, означает, что, если что-то не
-работает на этой версии, а на поддерживаемой работает - это не наша проблема, а их.
-Мы также запускаем наши CI-тесты на последней версии Ruby (предстоящей 1.9.3),
-но мы не можем ничего гарантировать, так как она постоянно развивается.
-Предполагается, что 1.9.3p0 будет поддерживаться.
-Sinatra должна работать на любой операционной системе, в которой есть одна из указанных выше версий Ruby.
-== На острие
-Если вы хотите использовать самый последний код Sinatra, не бойтесь запускать
-свое приложение вместе с кодом из master ветки Sinatra, она весьма стабильна.
-Мы также время от времени выпускаем предварительные версии, так что вы можете делать так:
-  gem install sinatra --pre
-Чтобы воспользоваться некоторыми самыми последними возможностями.
-=== С помощью Bundler
-Если вы хотите запускать свое приложение с последней версией Sinatra, то
-рекомендуем использовать {Bundler}[http://gembundler.com/].
-Сначала установите Bundler, если у вас его еще нет:
-  gem install bundler
-Затем создайте файл +Gemfile+ в директории вашего проекта:
-  source :rubygems
-  gem 'sinatra', :git => "git://github.com/sinatra/sinatra.git"
-  # другие зависимости
-  gem 'haml'                    # например, если используете haml
-  gem 'activerecord', '~> 3.0'  # может быть, вам нужен и ActiveRecord 3.x
-Обратите внимание, вам нужно будет указывать все зависимости вашего приложения
-в этом файле. Однако, непосредственные зависимости Sinatra (Rack и Tilt) Bundler
-автоматически скачает и добавит.
-Теперь вы можете запускать свое приложение так:
-  bundle exec ruby myapp.rb
-=== Вручную
-Создайте локальный клон репозитория и запускайте свое приложение с <tt>sinatra/lib</tt>
-директорией в <tt>$LOAD_PATH</tt>:
-  cd myapp
-  git clone git://github.com/sinatra/sinatra.git
-  ruby -Isinatra/lib myapp.rb
-Чтобы обновить исходники Sinatra:
-  cd myapp/sinatra
-  git pull
-=== Установка глобально
-Вы можете самостоятельно собрать gem:
-  git clone git://github.com/sinatra/sinatra.git
-  cd sinatra
-  rake sinatra.gemspec
-  rake install
-Если вы устанавливаете пакеты (gem) от пользователя root, то вашим следующим шагом должна быть команда
-  sudo rake install
-== Версии
-Sinatra использует {Semantic Versioning}[http://semver.org/], SemVer и
-SemVerTag.
-== Дальнейшее чтение
-* {Веб-сайт проекта}[http://www.sinatrarb.com/] - Дополнительная документация,
-  новости и ссылки на другие ресурсы.
-* {Участие в проекте}[http://www.sinatrarb.com/contributing] - Обнаружили баг? Нужна помощь? Написали патч?
-* {Слежение за проблемами/ошибками}[http://github.com/sinatra/sinatra/issues]
-* {Twitter}[http://twitter.com/sinatra]
-* {Группы рассылки}[http://groups.google.com/group/sinatrarb/topics]
-* {IRC: #sinatra}[irc://chat.freenode.net/#sinatra] на http://freenode.net
-* {Sinatra Book}[http://sinatra-book.gittr.com] учебник и сборник рецептов
-* {Sinatra Recipes}[http://recipes.sinatrarb.com/] сборник рецептов
-* API документация к {последнему релизу}[http://rubydoc.info/gems/sinatra]
-  или {текущему HEAD}[http://rubydoc.info/github/sinatra/sinatra] на
-  http://rubydoc.info