classicCMS 0.1.2

data/vendor/bundle/gems/sinatra-1.3.2/README.es.rdoc

@@ -0,0 +1,2043 @@
+= Sinatra
+<i>Atención: Este documento es una traducción de la versión en inglés y puede estar desactualizado.</i>
+
+Sinatra es un DSL para crear aplicaciones web rápidamente en Ruby con un mínimo
+esfuerzo:
+
+  # miapp.rb
+  require 'sinatra'
+
+  get '/' do
+    'Hola mundo!'
+  end
+
+Instalá la gem y ejecutá la aplicación con:
+
+  gem install sinatra
+  ruby -rubygems miapp.rb
+
+Podés verla en: http://localhost:4567
+
+Es recomendable además ejecutar <tt>gem install thin</tt>, ya que Sinatra lo va
+a utilizar cuando esté disponible.
+
+== Rutas
+
+En Sinatra, una ruta está compuesta por un método HTTP y un patrón de una URL.
+Cada ruta se asocia con un bloque:
+
+  get '/' do
+    .. mostrar algo ..
+  end
+
+  post '/' do
+    .. crear algo ..
+  end
+
+  put '/' do
+    .. reemplazar algo ..
+  end
+
+  patch '/' do
+    .. modificar algo ..
+  end
+
+  delete '/' do
+    .. aniquilar algo ..
+  end
+
+  options '/' do
+    .. informar algo ..
+  end
+
+
+Las rutas son comparadas en el orden en el que son definidas. La primer ruta
+que coincide con la petición es invocada.
+
+Los patrones de las rutas pueden incluir parámetros nombrados, accesibles a
+través de el hash <tt>params</tt>:
+
+  get '/hola/:nombre' do
+    # coincide con "GET /hola/foo" y "GET /hola/bar"
+    # params[:nombre] es 'foo' o 'bar'
+    "Hola #{params[:nombre]}!"
+  end
+
+También podés acceder a los parámetros nombrados usando parámetros de bloque:
+
+  get '/hola/:nombre' do |n|
+    "Hola #{n}!"
+  end
+
+Los patrones de ruta también pueden incluir parámetros splat (o wildcard),
+accesibles a través del arreglo <tt>params[:splat]</tt>:
+
+  get '/decir/*/al/*' do
+    # coincide con /decir/hola/al/mundo
+    params[:splat] # => ["hola", "mundo"]
+  end
+
+  get '/descargar/*.*' do
+    # coincide con /descargar/path/al/archivo.xml
+    params[:splat] # => ["path/al/archivo", "xml"]
+  end
+
+O, con parámetros de bloque:
+
+  get '/descargar/*.*' do |path, ext|
+    [path, ext] # => ["path/al/archivo", "xml"]
+  end
+
+Rutas con Expresiones Regulares:
+
+  get %r{/hola/([\w]+)} do
+    "Hola, #{params[:captures].first}!"
+  end
+
+O con un parámetro de bloque:
+
+  get %r{/hola/([\w]+)} do |c|
+    "Hola, #{c}!"
+  end
+
+Los patrones de ruta pueden contener parámetros opcionales:
+
+  get '/posts.?:formato?' do
+    # coincide con "GET /posts" y además admite cualquier extensión, por
+    # ejemplo, "GET /posts.json", "GET /posts.xml", etc.
+  end
+
+A propósito, a menos que desactivés la protección para el ataque <em>path
+traversal</em> (ver más abajo), el path de la petición puede ser modificado
+antes de que se compare con los de tus rutas.
+
+=== Condiciones
+
+Las rutas pueden incluir una variedad de condiciones de selección, como por
+ejemplo el user agent:
+
+  get '/foo', :agent => /Songbird (\d\.\d)[\d\/]*?/ do
+    "Estás usando la versión de Songbird #{params[:agent][0]}"
+  end
+
+  get '/foo' do
+    # Coincide con browsers que no sean songbird
+  end
+
+Otras condiciones disponibles son +host_name+ y +provides+:
+
+  get '/', :host_name => /^admin\./ do
+    "Área de Administración, Acceso denegado!"
+  end
+
+  get '/', :provides => 'html' do
+    haml :index
+  end
+
+  get '/', :provides => ['rss', 'atom', 'xml'] do
+    builder :feed
+  end
+
+Podés definir tus propias condiciones fácilmente:
+
+  set(:probabilidad) { |valor| condition { rand <= valor } }
+
+  get '/gana_un_auto', :probabilidad => 0.1 do
+    "Ganaste!"
+  end
+
+  get '/gana_un_auto' do
+    "Lo siento, perdiste."
+  end
+
+Si tu condición acepta más de un argumento, podés pasarle un arreglo.  Al
+definir la condición puede resultarte conveniente utilizar el operador splat en
+la lista de parámetros:
+
+  set(:autorizar) do |*roles|   # <- mirá el splat
+    condition do
+      unless sesion_iniciada? && roles.any? {|rol| usuario_actual.tiene_rol? rol }
+        redirect "/iniciar_sesion/", 303
+      end
+    end
+  end
+
+  get "/mi/cuenta/", :autorizar => [:usuario, :administrador] do
+    "Detalles de mi cuenta"
+  end
+
+  get "/solo/administradores/", :autorizar => :administrador do
+    "Únicamente para administradores!"
+  end
+
+=== Valores de Retorno
+
+El valor de retorno de un bloque de ruta determina al menos el cuerpo de la
+respuesta que se le pasa al cliente HTTP o al siguiente middleware en la pila
+de Rack. Lo más común es que sea un string, como en los ejemplos anteriores.
+Sin embargo, otros valor también son aceptados.
+
+Podés devolver cualquier objeto que sea una respuesta Rack válida, un objeto
+que represente el cuerpo de una respuesta Rack o un código de estado HTTP:
+
+* Un arreglo con tres elementos: <tt>[estado (Fixnum), cabeceras (Hash), cuerpo de la respuesta (responde a #each)]</tt>
+* Un arreglo con dos elementos: <tt>[estado (Fixnum), cuerpo de la respuesta (responde a #each)]</tt>
+* Un objeto que responde a <tt>#each</tt> y que le pasa únicamente strings al bloque dado
+* Un Fixnum representando el código de estado
+
+De esa manera podemos, por ejemplo, implementar fácilmente un streaming:
+
+    class Stream
+      def each
+        100.times { |i| yield "#{i}\n" }
+      end
+    end
+
+    get('/') { Stream.new }
+
+=== Comparadores de Rutas Personalizados
+
+Como se mostró anteriormente, Sinatra permite utilizar Strings y expresiones
+regulares para definir las rutas.  Sin embargo, la cosa no termina ahí.  Podés
+definir tus propios comparadores muy fácilmente:
+
+  class PattronCualquieraMenos
+    Match = Struct.new(:captures)
+
+    def initialize(excepto)
+      @excepto  = excepto
+      @capturas = Match.new([])
+    end
+
+    def match(str)
+      @capturas unless @excepto === str
+    end
+  end
+
+  def cualquiera_menos(patron)
+    PatronCualquieraMenos.new(patron)
+  end
+
+  get cualquiera_menos("/index") do
+    # ...
+  end
+
+Tené en cuenta que el ejemplo anterior es un poco rebuscado.  Un resultado
+similar puede conseguirse más sencillamente:
+
+  get // do
+    pass if request.path_info == "/index"
+    # ...
+  end
+
+O, usando un lookahead negativo:
+
+  get %r{^(?!/index$)} do
+    # ...
+  end
+
+== Archivos Estáticos
+
+Los archivos estáticos son servidos desde el directorio público
+<tt>./public</tt>. Podés especificar una ubicación diferente ajustando la
+opción <tt>:public_folder</tt>:
+
+  set :public_folder, File.dirname(__FILE__) + '/estaticos'
+
+Notá que el nombre del directorio público no está incluido en la URL. Por
+ejemplo, el archivo <tt>./public/css/style.css</tt> se accede a través de
+<tt>http://ejemplo.com/css/style.css</tt>.
+
+Usá la configuración <tt>:static_cache_control</tt> para agregar el encabezado
+<tt>Cache-Control</tt> (ver la sección de configuración para más detalles).
+
+== Vistas / Plantillas
+
+Cada lenguaje de plantilla se expone a través de un método de renderizado que
+lleva su nombre.  Estos métodos simplemente devuelven un string:
+
+  get '/' do
+    erb :index
+  end
+
+Renderiza <tt>views/index.erb</tt>.
+
+En lugar del nombre de la plantilla podés proporcionar directamente el
+contenido de la misma:
+
+  get '/' do
+    codigo = "<%= Time.now %>"
+    erb codigo
+  end
+
+Los métodos de renderizado, aceptan además un segundo argumento, el hash de
+opciones:
+
+  get '/' do
+    erb :index, :layout => :post
+  end
+
+Renderiza <tt>views/index.erb</tt> embebido en <tt>views/post.erb</tt> (por
+defecto, la plantilla :index es embebida en <tt>views/layout.erb</tt> siempre y
+cuando este último archivo exista).
+
+Cualquier opción que Sinatra no entienda le será pasada al motor de renderizado
+de la plantilla:
+
+  get '/' do
+    haml :index, :format => :html5
+  end
+
+Además podés definir las opciones para un lenguaje de plantillas de forma
+general:
+
+  set :haml, :format => :html5
+
+  get '/' do
+    haml :index
+  end
+
+Las opciones pasadas al método de renderizado tienen precedencia sobre las
+definidas mediante +set+.
+
+Opciones disponibles:
+
+[locals]
+  Lista de variables locales pasadas al documento.  Resultan muy útiles cuando
+  se combinan con parciales.
+  Ejemplo: <tt>erb "<%= foo %>", :locals => {:foo => "bar"}</tt>
+
+[default_encoding]
+  Encoding utilizado cuando el de un string es dudoso.  Por defecto toma el
+  valor de <tt>settings.default_encoding</tt>.
+
+[views]
+  Directorio desde donde se cargan las vistas.  Por defecto toma el valor de
+  <tt>settings.views</tt>.
+
+[layout]
+  Si es +true+ o +false+ indica que se debe usar, o nó, un layout,
+  respectivamente.  También puede ser un símbolo que especifique qué plantilla
+  usar.  Ejemplo: <tt>erb :index, :layout => !request.xhr?</tt>
+
+[content_type]
+  Content-Type que produce la plantilla.  El valor por defecto depende de cada
+  lenguaje de plantillas.
+
+[scope]
+  Ámbito en el que se renderiza la plantilla.  Por defecto utiliza la instancia
+  de la aplicación.  Tené en cuenta que si cambiás esta opción las variables de
+  instancia y los helpers van a dejar de estar disponibles.
+
+[layout_engine]
+  Motor de renderizado de plantillas que usa para el layout.  Resulta
+  conveniente para lenguajes que no soportan layouts.  Por defecto toma el valor
+  del motor usado para renderizar la plantilla.
+  Ejemplo: <tt>set :rdoc, :layout_engine => :erb</tt>
+
+Se asume que las plantillas están ubicadas directamente bajo el directorio
+<tt>./views</tt>. Para usar un directorio de vistas diferente:
+
+  set :views, settings.root + '/plantillas'
+
+Es importante acordarse que siempre tenés que referenciar a las plantillas con
+símbolos, incluso cuando se encuentran en un subdirectorio (en este caso tenés
+que usar <tt>:'subdir/plantilla'</tt>). Tenés que usar un símbolo porque los
+métodos de renderización van a renderizar directamente cualquier string que se
+les pase como argumento.
+
+=== Lenguajes de Plantillas Disponibles
+
+Algunos lenguajes tienen varias implementaciones.  Para especificar que
+implementación usar (y para ser thread-safe), deberías requerirla antes de
+usarla:
+
+  require 'rdiscount' # o require 'bluecloth'
+  get('/') { markdown :index }
+
+=== Plantillas Haml
+
+Dependencias::             {haml}[http://haml-lang.com/]
+Extensiones de Archivo::   <tt>.haml</tt>
+Ejemplo::                  <tt>haml :index, :format => :html5</tt>
+
+=== Plantillas Erb
+
+Dependencias::             {erubis}[http://www.kuwata-lab.com/erubis/] o
+                           erb (incluida en Ruby)
+Extensiones de Archivo::   <tt>.erb</tt>, <tt>.rhtml</tt> o <tt>.erubis</tt>
+                           (solamente con Erubis)
+Ejemplo::                  <tt>erb :index</tt>
+
+=== Plantillas Builder
+
+Dependencias::             {builder}[http://builder.rubyforge.org/]
+Extensiones de Archivo::   <tt>.builder</tt>
+Ejemplo::                  <tt>builder { |xml| xml.em "hola" }</tt>
+
+Además, acepta un bloque con la definición de la plantilla (ver el ejemplo).
+
+=== Plantillas Nokogiri
+
+Dependencias::             {nokogiri}[http://nokogiri.org/]
+Extensiones de Archivo::   <tt>.nokogiri</tt>
+Ejemplo::                  <tt>nokogiri { |xml| xml.em "hola" }</tt>
+
+Además, acepta un bloque con la definición de la plantilla (ver el ejemplo).
+
+=== Plantillas Sass
+
+Dependencias::             {sass}[http://sass-lang.com/]
+Extensiones de Archivo::   <tt>.sass</tt>
+Ejemplo::                  <tt>sass :stylesheet, :style => :expanded</tt>
+
+=== Plantillas SCSS
+
+Dependencias::             {scss}[http://sass-lang.com/]
+Extensiones de Archivo::   <tt>.scss</tt>
+Ejemplo::                  <tt>scss :stylesheet, :style => :expanded</tt>
+
+=== Plantillas Less
+
+Dependencias::             {less}[http://www.lesscss.org/]
+Extensiones de Archivo::   <tt>.less</tt>
+Ejemplo::                  <tt>less :stylesheet</tt>
+
+=== Plantillas Liquid
+
+Dependencias::             {liquid}[http://www.liquidmarkup.org/]
+Extensiones de Archivo::   <tt>.liquid</tt>
+Ejemplo::                  <tt>liquid :index, :locals => { :clave => 'valor' }</tt>
+
+Como no vas a poder llamar a métodos de Ruby (excepto por +yield+) desde una
+plantilla Liquid, casi siempre vas a querer pasarle locales.
+
+=== Plantillas Markdown
+
+Dependencias::             {rdiscount}[https://github.com/rtomayko/rdiscount],
+                           {redcarpet}[https://github.com/tanoku/redcarpet],
+                           {bluecloth}[http://deveiate.org/projects/BlueCloth],
+                           {kramdown}[http://kramdown.rubyforge.org/] *o*
+                           {maruku}[http://maruku.rubyforge.org/]
+Extensiones de Archivo::   <tt>.markdown</tt>, <tt>.mkd</tt> y <tt>.md</tt>
+Ejemplo::                  <tt>markdown :index, :layout_engine => :erb</tt>
+
+No es posible llamar métodos desde markdown, ni pasarle locales. Por lo tanto,
+generalmente vas a usarlo en combinación con otro motor de renderizado:
+
+  erb :resumen, :locals => { :texto => markdown(:introduccion) }
+
+Tené en cuenta que también podés llamar al método +markdown+ desde otras
+plantillas:
+
+  %h1 Hola Desde Haml!
+  %p= markdown(:saludos)
+
+Como no podés utilizar Ruby desde Markdown, no podés usar layouts escritos en
+Markdown. De todos modos, es posible usar un motor de renderizado para el
+layout distinto al de la plantilla pasando la opción <tt>:layout_engine</tt>.
+
+=== Plantillas Textile
+
+Dependencias::             {RedCloth}[http://redcloth.org/]
+Extensiones de Archivo::   <tt>.textile</tt>
+Ejemplo::                  <tt>textile :index, :layout_engine => :erb</tt>
+
+No es posible llamar métodos desde textile, ni pasarle locales. Por lo tanto,
+generalmente vas a usarlo en combinación con otro motor de renderizado:
+
+  erb :resumen, :locals => { :texto => textile(:introduccion) }
+
+Tené en cuenta que también podés llamar al método +textile+ desde otras
+plantillas:
+
+  %h1 Hola Desde Haml!
+  %p= textile(:saludos)
+
+Como no podés utilizar Ruby desde Textile, no podés usar layouts escritos en
+Textile. De todos modos, es posible usar un motor de renderizado para el
+layout distinto al de la plantilla pasando la opción <tt>:layout_engine</tt>.
+
+=== Plantillas RDoc
+
+Dependencias::             {rdoc}[http://rdoc.rubyforge.org/]
+Extensiones de Archivo::   <tt>.rdoc</tt>
+Ejemplo::                  <tt>rdoc :LEEME, :layout_engine => :erb</tt>
+
+No es posible llamar métodos desde rdoc, ni pasarle locales. Por lo tanto,
+generalmente vas a usarlo en combinación con otro motor de renderizado:
+
+  erb :resumen, :locals => { :texto => rdoc(:introduccion) }
+
+Tené en cuenta que también podés llamar al método +rdoc+ desde otras
+plantillas:
+
+  %h1 Hola Desde Haml!
+  %p= rdoc(:saludos)
+
+Como no podés utilizar Ruby desde RDoc, no podés usar layouts escritos en RDoc.
+De todos modos, es posible usar un motor de renderizado para el layout distinto
+al de la plantilla pasando la opción <tt>:layout_engine</tt>.
+
+=== Plantillas Radius
+
+Dependencias::             {radius}[http://radius.rubyforge.org/]
+Extensiones de Archivo::   <tt>.radius</tt>
+Ejemplo::                  <tt>radius :index, :locals => { :clave => 'valor' }</tt>
+
+Como no vas a poder llamar a métodos de Ruby (excepto por +yield+) desde una
+plantilla Radius, casi siempre vas a querer pasarle locales.
+
+=== Plantillas Markaby
+
+Dependencias::             {markaby}[http://markaby.github.com/]
+Extensiones de Archivo::   <tt>.mab</tt>
+Ejemplos::                 <tt>markaby { h1 "Bienvenido!" }</tt>
+
+Además, acepta un bloque con la definición de la plantilla (ver el ejemplo).
+
+=== Plantillas Slim
+
+Dependencias::             {slim}[http://slim-lang.com/]
+Extensiones de Archivo::   <tt>.slim</tt>
+Ejemplo::                  <tt>slim :index</tt>
+
+=== Plantillas Creole
+
+Dependencias::             {creole}[https://github.com/minad/creole]
+Extensiones de Archivo::   <tt>.creole</tt>
+Ejemplo::                  <tt>creole :wiki, :layout_engine => :erb</tt>
+
+No es posible llamar métodos desde creole, ni pasarle locales. Por lo tanto,
+generalmente vas a usarlo en combinación con otro motor de renderizado:
+
+  erb :resumen, :locals => { :texto => cerole(:introduccion) }
+
+Tené en cuenta que también podés llamar al método +creole+ desde otras
+plantillas:
+
+  %h1 Hola Desde Haml!
+  %p= creole(:saludos)
+
+Como no podés utilizar Ruby desde Creole, no podés usar layouts escritos en
+Creloe.  De todos modos, es posible usar un motor de renderizado para el layout
+distinto al de la plantilla pasando la opción <tt>:layout_engine</tt>.
+
+=== Plantillas CoffeeScript
+
+Dependencias::             {coffee-script}[https://github.com/josh/ruby-coffee-script]
+                           y un {mecanismo para ejecutar javascript}[https://github.com/sstephenson/execjs/blob/master/README.md#readme]
+Extensiones de Archivo::   <tt>.coffee</tt>
+Ejemplo::                  <tt>coffee :index</tt>
+
+=== Plantillas Embebidas
+
+  get '/' do
+    haml '%div.titulo Hola Mundo'
+  end
+
+Renderiza el template embebido en el string.
+
+=== Accediendo a Variables en Plantillas
+
+Las plantillas son evaluadas dentro del mismo contexto que los manejadores de
+ruta. Las variables de instancia asignadas en los manejadores de ruta son
+accesibles directamente por las plantillas:
+
+  get '/:id' do
+    @foo = Foo.find(params[:id])
+    haml '%h1= @foo.nombre'
+  end
+
+O es posible especificar un Hash de variables locales explícitamente:
+
+  get '/:id' do
+    foo = Foo.find(params[:id])
+    haml '%h1= bar.nombre', :locals => { :bar => foo }
+  end
+
+Esto es usado típicamente cuando se renderizan plantillas como parciales desde
+adentro de otras plantillas.
+
+=== Plantillas Inline
+
+Las plantillas pueden ser definidas al final del archivo fuente:
+
+  require 'rubygems'
+  require 'sinatra'
+
+  get '/' do
+    haml :index
+  end
+
+  __END__
+
+  @@ layout
+  %html
+    = yield
+
+  @@ index
+  %div.titulo Hola mundo!!!!!
+
+NOTA: únicamente las plantillas inline definidas en el archivo fuente que
+requiere sinatra son cargadas automáticamente. Llamá <tt>enable
+:inline_templates</tt> explícitamente si tenés plantillas inline en otros
+archivos fuente.
+
+=== Plantillas Nombradas
+
+Las plantillas también pueden ser definidas usando el método top-level
+<tt>template</tt>:
+
+  template :layout do
+    "%html\n  =yield\n"
+  end
+
+  template :index do
+    '%div.titulo Hola Mundo!'
+  end
+
+  get '/' do
+    haml :index
+  end
+
+Si existe una plantilla con el nombre "layout", va a ser usada cada vez que
+una plantilla es renderizada. Podés desactivar los layouts individualmente
+pasando <tt>:layout => false</tt> o globalmente con
+<tt>set :haml, :layout => false</tt>:
+
+  get '/' do
+    haml :index, :layout => !request.xhr?
+  end
+
+=== Asociando Extensiones de Archivo
+
+Para asociar una extensión de archivo con un motor de renderizado, usá
+<tt>Tilt.register</tt>. Por ejemplo, si querés usar la extensión +tt+ para
+las plantillas Textile, podés hacer lo siguiente:
+
+  Tilt.register :tt, Tilt[:textile]
+
+=== Agregando Tu Propio Motor de Renderizado
+
+Primero, registrá tu motor con Tilt, y después, creá tu método de renderizado:
+
+  Tilt.register :mipg, MiMotorParaPlantillaGenial
+
+  helpers do
+    def mypg(*args) render(:mypg, *args) end
+  end
+
+  get '/' do
+    mypg :index
+  end
+
+Renderiza <tt>./views/index.mypg</tt>. Mirá https://github.com/rtomayko/tilt
+para aprender más de Tilt.
+
+== Filtros
+
+Los filtros +before+ son evaluados antes de cada petición dentro del mismo
+contexto que las rutas. Pueden modificar la petición y la respuesta.  Las
+variables de instancia asignadas en los filtros son accesibles por las rutas y
+las plantillas:
+
+  before do
+    @nota = 'Hey!'
+    request.path_info = '/foo/bar/baz'
+  end
+
+  get '/foo/*' do
+    @nota #=> 'Hey!'
+    params[:splat] #=> 'bar/baz'
+  end
+
+Los filtros +after+ son evaluados después de cada petición dentro del mismo
+contexto y también pueden modificar la petición y la respuesta.  Las variables
+de instancia asignadas en los filtros +before+ y en las rutas son accesibles por
+los filtros +after+:
+
+  after do
+    puts response.status
+  end
+
+Nota: A menos que usés el método +body+ en lugar de simplemente devolver un
+string desde una ruta, el cuerpo de la respuesta no va a estar disponible en
+un filtro after, debido a que todavía no se ha generado.
+
+Los filtros aceptan un patrón opcional, que cuando está presente causa que los
+mismos sean evaluados únicamente si el path de la petición coincide con ese
+patrón:
+
+  before '/protegido/*' do
+    autenticar!
+  end
+
+  after '/crear/:slug' do |slug|
+    session[:ultimo_slug] = slug
+  end
+
+Al igual que las rutas, los filtros también pueden aceptar condiciones:
+
+  before :agent => /Songbird/ do
+    # ...
+  end
+
+  after '/blog/*', :host_name => 'ejemplo.com' do
+    # ...
+  end
+
+== Ayudantes
+
+Usá el método top-level <tt>helpers</tt> para definir métodos ayudantes que
+pueden ser utilizados dentro de los manejadores de rutas y las plantillas:
+
+  helpers do
+    def bar(nombre)
+      "#{nombre}bar"
+    end
+  end
+
+  get '/:nombre' do
+    bar(params[:nombre])
+  end
+
+=== Usando Sesiones
+
+Una sesión es usada para mantener el estado a través de distintas peticiones.
+Cuando están activadas, tenés un hash de sesión para cada sesión de usuario:
+
+  enable :sessions
+
+  get '/' do
+    "valor = " << session[:valor].inspect
+  end
+
+  get '/:valor' do
+    session[:valor] = params[:valor]
+  end
+
+Tené en cuenta que <tt>enable :sessions</tt> guarda todos los datos en una
+cookie, lo que no es siempre deseable (guardar muchos datos va a incrementar
+tu tráfico, por citar un ejemplo).  Podés usar cualquier middleware Rack para
+manejar sesiones, de la misma manera que usarías cualquier otro middleware,
+pero con la salvedad de que *no* tenés que llamar a <tt>enable :sessions</tt>:
+
+  use Rack::Session::Pool, :expire_after => 2592000
+
+  get '/' do
+    "valor = " << session[:valor].inspect
+  end
+
+  get '/:valor' do
+    session[:valor] = params[:valor]
+  end
+
+Para incrementar la seguridad, los datos de la sesión almacenados en
+la cookie son firmados con un secreto de sesión.  Este secreto, es
+generado aleatoriamente por Sinatra.  De cualquier manera, hay que
+tener en cuenta que cada vez que inicies la aplicación se va a generar
+uno nuevo.  Así, si querés que todas las instancias de tu aplicación
+compartan un único secreto, tenés que definirlo vos:
+
+  set :session_secret, 'super secreto'
+
+Si necesitás una configuración más específica, +sessions+ acepta un
+Hash con opciones:
+
+  set :sessions, :domain => 'foo.com'
+
+=== Interrupción
+
+Para detener inmediatamente una petición dentro de un filtro o una ruta usá:
+
+  halt
+
+También podés especificar el estado:
+
+  halt 410
+
+O el cuerpo:
+
+  halt 'esto va a ser el cuerpo'
+
+O los dos:
+
+  halt 401, 'salí de acá!'
+
+Con cabeceras:
+
+  halt 402, { 'Content-Type' => 'text/plain' }, 'venganza'
+
+Obviamente, es posible utilizar +halt+ con una plantilla:
+
+  halt erb(:error)
+
+=== Paso
+
+Una ruta puede pasarle el procesamiento a la siguiente ruta que coincida con
+la petición usando <tt>pass</tt>:
+
+  get '/adivina/:quien' do
+    pass unless params[:quien] == 'Franco'
+    'Adivinaste!'
+  end
+
+  get '/adivina/*' do
+    'Erraste!'
+  end
+
+Se sale inmediatamente del bloque de la ruta y se le pasa el control a la
+siguiente ruta que coincida. Si no coincide ninguna ruta, se devuelve un 404.
+
+=== Ejecutando Otra Ruta
+
+Cuando querés obtener el resultado de la llamada a una ruta, +pass+ no te va a
+servir.  Para lograr esto, podés usar +call+:
+
+  get '/foo' do
+    status, headers, body = call env.merge("PATH_INFO" => '/bar')
+    [status, headers, body.map(&:upcase)]
+  end
+
+  get '/bar' do
+    "bar"
+  end
+
+Notá que en el ejemplo anterior, es conveniente mover <tt>"bar"</tt> a un
+helper, y llamarlo desde <tt>/foo</tt> y <tt>/bar</tt>.  Así, vas a simplificar
+las pruebas y a mejorar el rendimiento.
+
+Si querés que la petición se envíe a la misma instancia de la aplicación en
+lugar de a otra, usá <tt>call!</tt> en lugar de <tt>call</tt>.
+
+En la especificación de Rack podés encontrar más información sobre
+<tt>call</tt>.
+
+=== Asignando el Código de Estado, los Encabezados y el Cuerpo de una Respuesta
+
+Es posible, y se recomienda, asignar el código de estado y el cuerpo de una
+respuesta con el valor de retorno de una ruta.  De cualquier manera, en varios
+escenarios, puede que sea conveniente asignar el cuerpo en un punto arbitrario
+del flujo de ejecución con el método +body+.  A partir de ahí, podés usar ese
+mismo método para acceder al cuerpo de la respuesta:
+
+  get '/foo' do
+    body "bar"
+  end
+
+  after do
+    puts body
+  end
+
+También es posible pasarle un bloque a +body+, que será ejecutado por el Rack
+handler (podés usar esto para implementar streaming, mirá "Valores de retorno").
+
+De manera similar, también podés asignar el código de estado y encabezados:
+
+  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
+
+También, al igual que +body+, tanto +status+ como +headers+ pueden utilizarse
+para obtener sus valores cuando no se les pasa argumentos.
+
+=== Streaming De Respuestas
+
+A veces vas a querer empezar a enviar la respuesta a pesar de que todavía no
+terminaste de generar su cuerpo.  También es posible que, en algunos casos,
+quieras seguir enviando información hasta que el cliente cierre la conexión.
+Cuando esto ocurra, el +stream+ helper te va a ser de gran ayuda:
+
+  get '/' do
+    stream do |out|
+      out << "Esto va a ser legen -\n"
+      sleep 0.5
+      out << " (esperalo) \n"
+      sleep 1
+      out << "- dario!\n"
+    end
+  end
+
+Podés implementar APIs de streaming,
+{Server-Sent Events}[http://dev.w3.org/html5/eventsource/] y puede ser usado
+como base para {WebSockets}[http://es.wikipedia.org/wiki/WebSockets].  También
+puede ser usado para incrementar el throughput si solo una parte del contenido
+depende de un recurso lento.
+
+Hay que tener en cuenta que el comportamiento del streaming, especialmente el
+número de peticiones concurrentes, depende del servidor web utilizado para
+servir la aplicación.  Puede que algunos servidores, como es el caso de
+WEBRick, no soporten streaming directamente, así el cuerpo de la respuesta será
+enviado completamente de una vez cuando el bloque pasado a +stream+ finalice su
+ejecución.  Si estás usando Shotgun, el streaming no va a funcionar.
+
+Cuando se pasa +keep_open+ como parámetro, no se va a enviar el mensaje
++close+ al objeto de stream. Queda en vos cerrarlo en el punto de ejecución
+que quieras. Nuevamente, hay que tener en cuenta que este comportamiento es
+posible solo en servidores que soporten eventos, como Thin o Rainbows. El
+resto de los servidores van a cerrar el stream de todos modos:
+
+  set :server, :thin
+  conexiones = []
+
+  get '/' do
+    # mantenemos abierto el stream
+    stream(:keep_open) { |salida| conexiones << salida }
+  end
+
+  post '/' do
+    # escribimos a todos los streams abiertos
+    conexiones.each { |salida| salida << params[:mensaje] << "\n" }
+    "mensaje enviado"
+  end
+
+=== Log (Registro)
+
+En el ámbito de la petición, el helper +logger+ (registrador) expone
+una instancia de +Logger+:
+
+  get '/' do
+    logger.info "cargando datos"
+    # ...
+  end
+
+Este logger tiene en cuenta la configuración de logueo de tu Rack
+handler.  Si el logueo está desactivado, este método va a devolver un
+objeto que se comporta como un logger pero que en realidad no hace
+nada.  Así, no vas a tener que preocuparte por esta situación.
+
+Tené en cuenta que el logueo está habilitado por defecto únicamente
+para <tt>Sinatra::Application</tt>.  Si heredaste de
+<tt>Sinatra::Base</tt>, probablemente quieras habilitarlo manualmente:
+
+  class MiApp < Sinatra::Base
+    configure :production, :development do
+      enable :logging
+    end
+  end
+
+Para evitar que se inicialice cualquier middleware de logging, configurá
++logging+ a +nil+.  Tené en cuenta que, cuando hagas esto, +logger+ va a
+devolver +nil+.  Un caso común es cuando querés usar tu propio logger. Sinatra
+va a usar lo que encuentre en <tt>env['rack.logger']</tt>.
+
+=== Tipos Mime
+
+Cuando usás <tt>send_file</tt> o archivos estáticos tal vez tengas tipos mime
+que Sinatra no entiende. Usá +mime_type+ para registrarlos a través de la
+extensión de archivo:
+
+  configure do
+    mime_type :foo, 'text/foo'
+  end
+
+También lo podés usar con el ayudante +content_type+:
+
+  get '/' do
+    content_type :foo
+    "foo foo foo"
+  end
+
+=== Generando URLs
+
+Para generar URLs deberías usar el método +url+.  Por ejemplo, en Haml:
+
+  %a{:href => url('/foo')} foo
+
+Tiene en cuenta proxies inversos y encaminadores de Rack, si están presentes.
+
+Este método también puede invocarse mediante su alias +to+  (mirá un ejemplo
+a continuación).
+
+=== Redirección del Navegador
+
+Podés redireccionar al navegador con el método +redirect+:
+
+  get '/foo' do
+    redirect to('/bar')
+  end
+
+Cualquier parámetro adicional se utiliza de la misma manera que los argumentos
+pasados a +halt+:
+
+  redirect to('/bar'), 303
+  redirect 'http://google.com', 'te confundiste de lugar, compañero'
+
+También podés redireccionar fácilmente de vuelta hacia la página desde donde
+vino el usuario con +redirect back+:
+
+  get '/foo' do
+    "<a href='/bar'>hacer algo</a>"
+  end
+
+  get '/bar' do
+    hacer_algo
+    redirect back
+  end
+
+Para pasar argumentos con una redirección, podés agregarlos a la cadena de
+búsqueda:
+
+  redirect to('/bar?suma=42')
+
+O usar una sesión:
+
+  enable :sessions
+
+  get '/foo' do
+    session[:secreto] = 'foo'
+    redirect to('/bar')
+  end
+
+  get '/bar' do
+    session[:secreto]
+  end
+
+=== Cache Control
+
+Asignar tus encabezados correctamente es el cimiento para realizar un cacheo
+HTTP correcto.
+
+Podés asignar el encabezado Cache-Control fácilmente:
+
+  get '/' do
+    cache_control :public
+    "cachealo!"
+  end
+
+Pro tip: configurar el cacheo en un filtro +before+:
+
+  before do
+    cache_control :public, :must_revalidate, :max_age => 60
+  end
+
+Si estás usando el helper +expires+ para definir el encabezado correspondiente,
+<tt>Cache-Control</tt> se va a definir automáticamente:
+
+  before do
+    expires 500, :public, :must_revalidate
+  end
+
+Para usar cachés adecuadamente, deberías considerar usar +etag+ o
++last_modified+.  Es recomendable que llames a estos helpers *antes* de hacer
+cualquier trabajo pesado, ya que van a enviar la respuesta inmediatamente si
+el cliente ya tiene la versión actual en su caché:
+
+  get '/articulo/:id' do
+    @articulo = Articulo.find params[:id]
+    last_modified @articulo.updated_at
+    etag @articulo.sha1
+    erb :articulo
+  end
+
+También es posible usar una
+{weak ETag}[http://en.wikipedia.org/wiki/HTTP_ETag#Strong_and_weak_validation]:
+
+  etag @articulo.sha1, :weak
+
+Estos helpers no van a cachear nada por vos, sino que van a facilitar la
+información necesaria para poder hacerlo.  Si estás buscando soluciones rápidas
+de cacheo con proxys inversos, mirá
+{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
+    "hola"
+  end
+
+Usá la configuración <tt>:static_cache_control</tt> para agregar el encabezado
+<tt>Cache-Control</tt> a archivos estáticos (ver la sección de configuración
+para más detalles).
+
+De acuerdo con la RFC 2616 tu aplicación debería comportarse diferente si a las
+cabeceras If-Match o If-None-Match se le asigna el valor <tt>*</tt> cuando el
+recurso solicitado ya existe.  Sinatra asume para peticiones seguras (como get)
+e idempotentes (como put) que el recurso existe, mientras que para el resto
+(como post), que no.  Podes cambiar este comportamiento con la opción
+<tt>:new_resource</tt>:
+
+  get '/crear' do
+    etag '', :new_resource => true
+    Articulo.create
+    erb :nuevo_articulo
+  end
+
+Si querés seguir usando una weak ETag, indicalo con la opción <tt>:kind</tt>:
+
+  etag '', :new_resource => true, :kind => :weak
+
+=== Enviando Archivos
+
+Para enviar archivos, podés usar el método <tt>send_file</tt>:
+
+  get '/' do
+    send_file 'foo.png'
+  end
+
+Además acepta un par de opciones:
+
+  send_file 'foo.png', :type => :jpg
+
+Estas opciones son:
+
+[filename]
+  nombre del archivo respondido, por defecto es el nombre real del archivo.
+
+[last_modified]
+  valor para el encabezado Last-Modified, por defecto toma el mtime del archivo.
+
+[type]
+  el content type que se va a utilizar, si no está presente se intenta adivinar
+  a partir de la extensión del archivo.
+
+[disposition]
+  se utiliza para el encabezado Content-Disposition, y puede tomar alguno de los
+  siguientes valores: +nil+ (por defecto), <tt>:attachment</tt> e
+  <tt>:inline</tt>
+
+[length]
+  encabezado Content-Length, por defecto toma el tamaño del archivo.
+
+Si el Rack handler lo soporta, se intentará no transmitir directamente desde el
+proceso de Ruby.  Si usás este método, Sinatra se va a encargar automáticamente
+peticiones de rango.
+
+=== Accediendo al objeto de la petición
+
+El objeto de la petición entrante puede ser accedido desde el nivel de la
+petición (filtros, rutas y manejadores de errores) a través del método
+<tt>request</tt>:
+
+  # app corriendo en http://ejemplo.com/ejemplo
+  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                # cuerpo de la petición enviado por el cliente (ver más abajo)
+    request.scheme              # "http"
+    request.script_name         # "/ejemplo"
+    request.path_info           # "/foo"
+    request.port                # 80
+    request.request_method      # "GET"
+    request.query_string        # ""
+    request.content_length      # longitud de request.body
+    request.media_type          # tipo de medio de request.body
+    request.host                # "ejemplo.com"
+    request.get?                # true (hay métodos análogos para los otros verbos)
+    request.form_data?          # false
+    request["UNA_CABECERA"]     # valor de la cabecera UNA_CABECERA
+    request.referrer            # la referencia del cliente o '/'
+    request.user_agent          # user agent (usado por la condición :agent)
+    request.cookies             # hash de las cookies del browser
+    request.xhr?                # es una petición ajax?
+    request.url                 # "http://ejemplo.com/ejemplo/foo"
+    request.path                # "/ejemplo/foo"
+    request.ip                  # dirección IP del cliente
+    request.secure?             # false (sería true sobre ssl)
+    request.forwarded?          # true (si se está corriendo atrás de un proxy inverso)
+    requuest.env                # hash de entorno directamente entregado por Rack
+  end
+
+Algunas opciones, como <tt>script_name</tt> o <tt>path_info</tt> pueden
+también ser escritas:
+
+  before { request.path_info = "/" }
+
+  get "/" do
+    "todas las peticiones llegan acá"
+  end
+
+El objeto <tt>request.body</tt> es una instancia de IO o StringIO:
+
+  post "/api" do
+    request.body.rewind  # en caso de que alguien ya lo haya leído
+    datos = JSON.parse request.body.read
+    "Hola #{datos['nombre']}!"
+  end
+
+=== Archivos Adjuntos
+
+Podés usar el método helper +attachment+ para indicarle al navegador que
+almacene la respuesta en el disco en lugar de mostrarla en pantalla:
+
+  get '/' do
+    attachment
+    "guardalo!"
+  end
+
+También podés pasarle un nombre de archivo:
+
+  get '/' do
+    attachment "info.txt"
+    "guardalo!"
+  end
+
+=== Fecha y Hora
+
+Sinatra pone a tu disposición el helper +time_for+, que genera un objeto +Time+
+a partir del valor que recibe como argumento.  Este valor puede ser un
++String+, pero también es capaz de convertir objetos +DateTime+, +Date+ y de
+otras clases similares:
+
+  get '/' do
+    pass if Time.now > time_for('Dec 23, 2012')
+    "todavía hay tiempo"
+  end
+
+Este método es usado internamente por métodos como +expires+ y +last_modified+,
+entre otros.  Por lo tanto, es posible extender el comportamiento de estos
+métodos sobreescribiendo +time_for+ en tu aplicación:
+
+  helpers do
+    def time_for(value)
+      case value
+      when :ayer then Time.now - 24*60*60
+      when :mañana then Time.now + 24*60*60
+      else super
+      end
+    end
+  end
+
+  get '/' do
+    last_modified :ayer
+    expires :mañana
+    "hola"
+  end
+
+=== Buscando los Archivos de las Plantillas
+
+El helper <tt>find_template</tt> se utiliza para encontrar los archivos de las
+plantillas que se van a renderizar:
+
+  find_template settings.views, 'foo', Tilt[:haml] do |archivo|
+    puts "podría ser #{archivo}"
+  end
+
+Si bien esto no es muy útil, lo interesante es que podés sobreescribir este
+método, y así enganchar tu propio mecanismo de búsqueda.  Por ejemplo, para
+poder utilizar más de un directorio de vistas:
+
+  set :views, ['vistas', 'plantillas']
+
+  helpers do
+    def find_template(views, name, engine, &block)
+      Array(views).each { |v| super(v, name, engine, &block) }
+    end
+  end
+
+Otro ejemplo consiste en usar directorios diferentes para los distintos motores
+de renderizado:
+
+  set :views, :sass => 'vistas/sass', :haml => 'plantillas', :defecto => 'vistas'
+
+  helpers do
+    def find_template(views, name, engine, &block)
+      _, folder = views.detect { |k,v| engine == Tilt[k] }
+      folder ||= views[:defecto]
+      super(folder, name, engine, &block)
+    end
+  end
+
+¡Es muy fácil convertir estos ejemplos en una extensión y compartirla!.
+
+Notá que <tt>find_template</tt> no verifica si un archivo existe realmente, sino
+que llama al bloque que recibe para cada path posible.  Esto no representa un
+problema de rendimiento debido a que +render+ va a usar +break+ ni bien
+encuentre un archivo que exista.  Además, las ubicaciones de las plantillas (y
+su contenido) se cachean cuando no estás en el modo de desarrollo.  Es bueno
+tener en cuenta lo anteiror si escribís un método medio loco.
+
+== Configuración
+
+Ejecutar una vez, en el inicio, en cualquier entorno:
+
+  configure do
+    # asignando una opción
+    set :opcion, 'valor'
+
+    # asignando varias opciones
+    set :a => 1, :b => 2
+
+    # atajo para `set :opcion, true`
+    enable :opcion
+
+    # atajo para `set :opcion, false`
+    disable :opcion
+
+    # también podés tener configuraciones dinámicas usando bloques
+    set(:css_dir) { File.join(views, 'css') }
+  end
+
+Ejecutar únicamente cuando el entorno (la variable de entorno RACK_ENV) es
+<tt>:production</tt>:
+
+  configure :production do
+    ...
+  end
+
+Ejecutar cuando el entorno es <tt>:production</tt> o <tt>:test</tt>:
+
+  configure :production, :test do
+    ...
+  end
+
+Podés acceder a estas opciones utilizando el método <tt>settings</tt>:
+
+  configure do
+    set :foo, 'bar'
+  end
+
+  get '/' do
+    settings.foo? # => true
+    settings.foo  # => 'bar'
+    ...
+  end
+
+=== Configurando la Protección de Ataques
+
+Sinatra usa {Rack::Protection}[https://github.com/rkh/rack-protection#readme]
+para defender a tu aplicación de los ataques más comunes.  Tenés que tener en
+cuenta que como consecuencia de esto puede venir asociada una disminución del
+rendimiento de tu aplicación.  Si por este, o algún otro motivo, querés
+desactivar está funcionalidad, podés hacerlo:
+
+  disable :protection
+
+También es posible desactivar una única capa de defensa:
+
+  set :protection, :except => :path_traversal
+
+O varias:
+
+  set :protection, :except => [:path_traversal, :session_hijacking]
+
+=== Configuraciones Disponibles
+
+[absolute_redirects]   si está deshabilitada, Sinatra va a permitir
+                       redirecciones relativas, sin embargo, como consecuencia
+                       de esto, va a dejar de cumplir con el RFC 2616 (HTTP
+                       1.1), que solamente permite redirecciones absolutas.
+
+                       Activalo si tu apliación está corriendo atrás de un proxy
+                       inverso que no se ha configurado adecuadamente.  Notá que
+                       el helper +url+ va a seguir produciendo URLs absolutas, a
+                       menos que le pasés +false+ como segundo parámetro.
+
+                       Deshabilitada por defecto.
+
+[add_charsets]         tipos mime a los que el helper <tt>content_type</tt> les
+                       añade automáticamente el charset.
+
+                       En general, no deberías asignar directamente esta opción,
+                       sino añadirle los charsets que quieras:
+
+                         settings.add_charsets << "application/foobar"
+
+[app_file]             path del archivo principal de la aplicación, se utiliza
+                       para detectar la raíz del proyecto, el directorio de las
+                       vistas y el público, así como las plantillas inline.
+
+[bind]                 dirección IP que utilizará el servidor integrado (por
+                       defecto: 0.0.0.0).
+
+[default_encoding]     encoding utilizado cuando el mismo se desconoce (por
+                       defecto <tt>"utf-8"</tt>).
+
+[dump_errors]          mostrar errores en el log.
+
+[environment]          entorno actual, por defecto toma el valor de
+                       <tt>ENV['RACK_ENV']</tt>, o <tt>"development"</tt> si no
+                       está disponible.
+
+[logging]              define si se utiliza el logger.
+
+[lock]                 coloca un lock alrededor de cada petición, procesando
+                       solamente una por proceso.
+
+                       Habilitá esta opción si tu aplicación no es thread-safe.
+                       Se encuentra deshabilitada por defecto.
+
+[method_override]      utiliza el parámetro <tt>_method</tt> para permtir
+                       formularios put/delete en navegadores que no los
+                       soportan.
+
+[port]                 puerto en el que escuchará el servidor integrado.
+
+[prefixed_redirects]   define si inserta <tt>request.script_name</tt> en las
+                       redirecciones cuando no se proporciona un path absoluto.
+                       De esta manera, cuando está habilitada,
+                       <tt>redirect '/foo'</tt> se comporta de la misma manera
+                       que <tt>redirect to('/foo')</tt>.  Se encuentra
+                       deshabilitada por defecto.
+
+[protection]           define si deben activarse las protecciones para los
+                       ataques web más comunes.  Para más detalles mirá la
+                       sección sobre la configuración de protección de ataques
+                       más arriba.
+
+[public_folder]        path del directorio desde donde se sirven los archivos
+                       públicos.  Solo se utiliza cuando se sirven archivos
+                       estáticos (ver la opción <tt>static</tt>).  Si no
+                       está presente, se infiere del valor de la opción
+                       <tt>app_file</tt>.
+
+[reload_templates]     define si se recargan las plantillas entre peticiones.
+
+                       Se encuentra activado en el entorno de desarrollo.
+
+[root]                 path del directorio raíz del proyecto.  Si no está
+                       presente, se infiere del valor de la opción
+                       <tt>app_file</tt>.
+
+[raise_errors]         elevar excepciones (detiene la aplicación).  Se
+                       encuentra activada por defecto cuando el valor de
+                       <tt>environment</tt>  es <tt>"test"</tt>.  En caso
+                       contrario estará desactivada.
+
+[run]                  cuando está habilitada, Sinatra se va a encargar de
+                       iniciar el servidor web, no la habilités cuando estés
+                       usando rackup o algún otro medio.
+
+[running]              indica si el servidor integrado está ejecutandose, ¡no
+                       cambiés esta configuración!.
+
+[server]               servidor, o lista de servidores, para usar como servidor
+                       integrado.  Por defecto: ['thin', 'mongrel', 'webrick'],
+                       el orden establece la prioridad.
+
+[sessions]             habilita el soporte de sesiones basadas en cookies a
+                       través de <tt>Rack::Session::Cookie</tt>.  Ver la
+                       sección 'Usando Sesiones' para más información.
+
+[show_exceptions]      muestra un stack trace en el navegador cuando ocurre una
+                       excepción.  Se encuentra activada por defecto cuando el
+                       valor de <tt>environment</tt> es <tt>"development"</tt>.
+                       En caso contrario estará desactivada.
+
+[static]               define si Sinatra debe encargarse de servir archivos
+                       estáticos.
+
+                       Deshabilitala cuando usés un servidor capaz de
+                       hacerlo por sí solo, porque mejorará el
+                       rendimiento.  Se encuentra habilitada por
+                       defecto en el estilo clásico y desactivado en el
+                       el modular.
+
+[static_cache_control] cuando Sinatra está sirviendo archivos estáticos, y
+                       está opción está habilitada, les va a agregar encabezados
+                       <tt>Cache-Control</tt> a las respuestas.  Para esto
+                       utiliza el helper +cache_control+.  Se encuentra
+                       deshabilitada por defecto.  Notar que es necesario
+                       utilizar un array cuando se asignan múltiples valores: 
+                       <tt>set :static_cache_control, [:public, :max_age => 300]</tt>.
+
+[views]                path del directorio de las vistas.  Si no está presente,
+                       se infiere del valor de la opción <tt>app_file</tt>.
+
+
+== Manejo de Errores
+
+Los manejadores de errores se ejecutan dentro del mismo contexto que las rutas
+y los filtros +before+, lo que significa que podés usar, por ejemplo,
+<tt>haml</tt>, <tt>erb</tt>, <tt>halt</tt>, etc.
+
+=== No encontrado <em>(Not Found)</em>
+
+Cuando se eleva una excepción <tt>Sinatra::NotFound</tt>, o el código de
+estado de la respuesta es 404, el manejador <tt>not_found</tt> es invocado:
+
+  not_found do
+    'No existo'
+  end
+
+=== Error
+
+El manejador +error+ es invocado cada vez que una excepción es elevada
+desde un bloque de ruta o un filtro. El objeto de la excepción se puede
+obtener de la variable Rack <tt>sinatra.error</tt>:
+
+  error do
+    'Disculpá, ocurrió un error horrible - ' + env['sinatra.error'].name
+  end
+
+Errores personalizados:
+
+  error MiErrorPersonalizado do
+    'Lo que pasó fue...' + env['sinatra.error'].message
+  end
+
+Entonces, si pasa esto:
+
+  get '/' do
+    raise MiErrorPersonalizado, 'algo malo'
+  end
+
+Obtenés esto:
+
+  Lo que pasó fue... algo malo
+
+También, podés instalar un manejador de errores para un código de estado:
+
+  error 403 do
+    'Acceso prohibido'
+  end
+
+  get '/secreto' do
+    403
+  end
+
+O un rango:
+
+  error 400..510 do
+    'Boom'
+  end
+
+Sinatra instala manejadores <tt>not_found</tt> y <tt>error</ttt> especiales
+cuando se ejecuta dentro del entorno de desarrollo "development".
+
+== Rack Middleware
+
+Sinatra corre sobre Rack[http://rack.rubyforge.org/], una interfaz minimalista
+que es un estándar para frameworks webs escritos en Ruby. Una de las
+capacidades más interesantes de Rack para los desarrolladores de aplicaciones
+es el soporte de "middleware" -- componentes que se ubican entre el servidor y
+tu aplicación, supervisando y/o manipulando la petición/respuesta HTTP para
+proporcionar varios tipos de funcionalidades comunes.
+
+Sinatra hace muy sencillo construir tuberías de Rack middleware a través del
+método top-level +use+:
+
+  require 'sinatra'
+  require 'mi_middleware_personalizado'
+
+  use Rack::Lint
+  use MiMiddlewarePersonalizado
+
+  get '/hola' do
+    'Hola Mundo'
+  end
+
+Las semánticas de +use+ son idénticas a las definidas para el DSL
+Rack::Builder[http://rack.rubyforge.org/doc/classes/Rack/Builder.html] (más
+frecuentemente usado desde archivos rackup). Por ejemplo, el método +use+
+acepta argumentos múltiples/variables así como bloques:
+
+  use Rack::Auth::Basic do |nombre_de_usuario, password|
+    nombre_de_usuario == 'admin' && password == 'secreto'
+  end
+
+Rack es distribuido con una variedad de middleware estándar para logging,
+debugging, enrutamiento URL, autenticación, y manejo de sesiones. Sinatra
+usa muchos de estos componentes automáticamente de acuerdo a su configuración
+para que típicamente no tengas que usarlas (con +use+) explícitamente.
+
+Podés encontrar middleware útil en
+{rack}[https://github.com/rack/rack/tree/master/lib/rack],
+{rack-contrib}[https://github.com/rack/rack-contrib#readme],
+con {CodeRack}[http://coderack.org/] o en la
+{Rack wiki}[https://github.com/rack/rack/wiki/List-of-Middleware].
+
+== Pruebas
+
+Las pruebas para las aplicaciones Sinatra pueden ser escritas utilizando
+cualquier framework o librería de pruebas basada en Rack. Se recomienda usar
+{Rack::Test}[http://rdoc.info/github/brynary/rack-test/master/frames]:
+
+  require 'mi_app_sinatra'
+  require 'test/unit'
+  require 'rack/test'
+
+  class MiAppTest < Test::Unit::TestCase
+    include Rack::Test::Methods
+
+    def app
+      Sinatra::Application
+    end
+
+    def test_mi_defecto
+      get '/'
+      assert_equal 'Hola Mundo!', last_response.body
+    end
+
+    def test_con_parametros
+      get '/saludar', :name => 'Franco'
+      assert_equal 'Hola Frank!', last_response.body
+    end
+
+    def test_con_entorno_rack
+      get '/', {}, 'HTTP_USER_AGENT' => 'Songbird'
+      assert_equal "Estás usando Songbird!", last_response.body
+    end
+  end
+
+== Sinatra::Base - Middleware, Librerías, y Aplicaciones Modulares
+
+Definir tu aplicación en el top-level funciona bien para micro-aplicaciones
+pero trae inconvenientes considerables a la hora de construir componentes
+reutilizables como Rack middleware, Rails metal, simple librerías con un
+componente de servidor, o incluso extensiones de Sinatra. El DSL de top-level
+contamina el espacio de nombres de Object y asume una configuración apropiada
+para micro-aplicaciones (por ejemplo, un único archivo de aplicación, los
+directorios <tt>./public</tt> y <tt>./views</tt>, logging, página con detalles
+de excepción, etc.). Ahí es donde <tt>Sinatra::Base</tt> entra en el juego:
+
+  require 'sinatra/base'
+
+  class MiApp < Sinatra::Base
+    set :sessions, true
+    set :foo, 'bar'
+
+    get '/' do
+      'Hola Mundo!'
+    end
+  end
+
+Las subclases de <tt>Sinatra::Base</tt> tienen disponibles exactamente los
+mismos métodos que los provistos por el DSL de top-level. La mayoría de las
+aplicaciones top-level se pueden convertir en componentes
+<tt>Sinatra::Base</tt> con dos modificaciones:
+
+* Tu archivo debe requerir <tt>sinatra/base</tt> en lugar de +sinatra+; de otra
+  manera, todos los métodos del DSL de sinatra son importados dentro del
+  espacio de nombres principal.
+* Poné las rutas, manejadores de errores, filtros y opciones de tu aplicación
+  en una subclase de <tt>Sinatra::Base</tt>.
+
+<tt>Sinatra::Base</tt> es una pizarra en blanco. La mayoría de las opciones están
+desactivadas por defecto, incluyendo el servidor incorporado. Mirá
+{Opciones y Configuraciones}[http://sinatra.github.com/configuration.html]
+para detalles sobre las opciones disponibles y su comportamiento.
+
+=== Estilo Modular vs. Clásico
+
+Contrariamente a la creencia popular, no hay nada de malo con el estilo clásico.
+Si se ajusta a tu aplicación, no es necesario que la cambies a una modular.
+
+Existen tan solo dos desventajas en comparación con el estilo modular:
+
+* Solamente podés tener una aplicación Sinatra por proceso Ruby - si tenés
+  planificado usar más, cambiá al estilo modular.
+
+* El estilo clásico contamina Object con métodos delegadores - si tenés
+  planificado empaquetar tu aplicación en una librería/gem, cambiá al estilo
+  modular.
+
+No hay ninguna razón por la cuál no puedas mezclar los estilos modular y
+clásico.
+
+Cuando cambiés de un estilo al otro, tené en cuenta las sutiles diferencias
+entre sus configuraciones:
+
+  Configuración       Clásica                      Modular
+
+  app_file            archivo que carga sinatra    archivo con la subclase de Sinatra::Base
+  run                 $0 == app_file               false
+  logging             true                         false
+  method_override     true                         false
+  inline_templates    true                         false
+  static              true                         false
+
+=== Sirviendo una Aplicación Modular
+
+Las dos opciones más comunes para iniciar una aplicación modular son, iniciarla
+activamente con <tt>run!</tt>:
+
+  # mi_app.rb
+  require 'sinatra/base'
+
+  class MiApp < Sinatra::Base
+    # ... código de la app  ...
+
+    # iniciar el servidor si el archivo fue ejecutado directamente
+    run! if app_file == $0
+  end
+
+Iniciar con:
+
+  ruby mi_app.rb
+
+O, con un archivo <tt>config.ru</tt>, que permite usar cualquier handler Rack:
+
+  # config.ru
+  require './mi_app'
+  run MiApp
+
+Después ejecutar:
+
+  rackup -p 4567
+
+=== Usando una Aplicación Clásica con un Archivo config.ru
+
+Escribí el archivo de tu aplicación:
+
+  # app.rb
+  require 'sinatra'
+
+  get '/' do
+    'Hola mundo!'
+  end
+
+Y el <tt>config.ru</tt> correspondiente:
+
+  require './app'
+  run Sinatra::Application
+
+=== ¿Cuándo Usar config.ru?
+
+Indicadores de que probablemente querés usar <tt>config.ru</tt>:
+
+* Querés realizar el deploy con un hanlder Rack distinto (Passenger, Unicorn,
+  Heroku, ...).
+* Querés usar más de una subclase de <tt>Sinatra::Base</tt>.
+* Querés usar Sinatra únicamente para middleware, pero no como un endpoint.
+
+<b>No hay necesidad de utilizar un archivo <tt>config.ru</tt> exclusivamente
+porque tenés una aplicación modular, y no necesitás una aplicación modular para
+iniciarla con <tt>config.ru</tt>.</b>
+
+=== Utilizando Sinatra como Middleware
+
+Sinatra no solo es capaz de usar otro Rack middleware, sino que a su vez,
+cualquier aplicación Sinatra puede ser agregada delante de un endpoint Rack
+como middleware. Este endpoint puede ser otra aplicación Sinatra, o cualquier
+aplicación basada en Rack (Rails/Ramaze/Camping/...):
+
+  require 'sinatra/base'
+
+  class PantallaDeLogin < Sinatra::Base
+    enable :sessions
+
+    get('/login') { haml :login }
+
+    post('/login') do
+      if params[:nombre] == 'admin' && params[:password] == 'admin'
+        session['nombre_de_usuario'] = params[:nombre]
+      else
+        redirect '/login'
+      end
+    end
+  end
+
+  class MiApp < Sinatra::Base
+    # el middleware se ejecutará antes que los filtros
+    use PantallaDeLogin
+
+    before do
+      unless session['nombre_de_usuario']
+        halt "Acceso denegado, por favor <a href='/login'>iniciá sesión</a>."
+      end
+    end
+
+    get('/') { "Hola #{session['nombre_de_usuario']}." }
+  end
+
+=== Creación Dinámica de Aplicaciones
+
+Puede que en algunas ocasiones quieras crear nuevas aplicaciones en
+tiempo de ejecución sin tener que asignarlas a una constante.  Para
+esto tenés <tt>Sinatra.new</tt>:
+
+  require 'sinatra/base'
+  mi_app = Sinatra.new { get('/') { "hola" } }
+  mi_app.run!
+
+Acepta como argumento opcional una aplicación desde la que se
+heredará:
+
+  # config.ru
+  require 'sinatra/base'
+
+  controller = Sinatra.new do
+    enable :logging
+    helpers MisHelpers
+  end
+
+  map('/a') do
+    run Sinatra.new(controller) { get('/') { 'a' } }
+  end
+
+  map('/b') do
+    run Sinatra.new(controller) { get('/') { 'b' } }
+  end
+
+Construir aplicaciones de esta forma resulta especialmente útil para
+testear extensiones Sinatra o para usar Sinatra en tus librerías.
+
+Por otro lado, hace extremadamente sencillo usar Sinatra como
+middleware:
+
+  require 'sinatra/base'
+
+  use Sinatra do
+    get('/') { ... }
+  end
+
+  run ProyectoRails::Application
+
+== Ámbitos y Ligaduras
+
+El ámbito en el que te encontrás determina que métodos y variables están
+disponibles.
+
+=== Ámbito de Aplicación/Clase
+
+Cada aplicación Sinatra es una subclase de <tt>Sinatra::Base</tt>. Si estás
+usando el DSL de top-level (<tt>require 'sinatra'</tt>), entonces esta clase es
+<tt>Sinatra::Application</tt>, de otra manera es la subclase que creaste
+explícitamente.  Al nivel de la clase tenés métodos como +get+ o +before+, pero
+no podés acceder a los objetos +request+ o +session+, ya que hay una única
+clase de la aplicación para todas las peticiones.
+
+Las opciones creadas utilizando +set+ son métodos al nivel de la clase:
+
+    class MiApp < Sinatra::Base
+      # Ey, estoy en el ámbito de la aplicación!
+      set :foo, 42
+      foo # => 42
+
+      get '/foo' do
+        # Hey, ya no estoy en el ámbito de la aplicación!
+      end
+    end
+
+Tenés la ligadura al ámbito de la aplicación dentro de:
+
+* El cuerpo de la clase de tu aplicación
+* Métodos definidos por extensiones
+* El bloque pasado a +helpers+
+* Procs/bloques usados como el valor para +set+
+
+Este ámbito puede alcanzarse de las siguientes maneras:
+
+* A través del objeto pasado a los bloques de configuración (<tt>configure { |c| ...}</tt>)
+* Llamando a +settings+ desde dentro del ámbito de la petición
+
+=== Ámbito de Petición/Instancia
+
+Para cada petición entrante, una nueva instancia de la clase de tu aplicación
+es creada y todos los bloques de rutas son ejecutados en ese ámbito. Desde este
+ámbito podés acceder a los objetos +request+ y +session+ o llamar a los métodos
+de renderización como +erb+ o +haml+. Podés acceder al ámbito de la aplicación
+desde el ámbito de la petición utilizando +settings+:
+
+  class MiApp < Sinatra::Base
+    # Ey, estoy en el ámbito de la aplicación!
+    get '/definir_ruta/:nombre' do
+      # Ámbito de petición para '/definir_ruta/:nombre'
+      @valor = 42
+
+      settings.get("/#{params[:nombre]}") do
+        # Ámbito de petición para "/#{params[:nombre]}"
+        @valor # => nil (no es la misma petición)
+      end
+
+      "Ruta definida!"
+    end
+  end
+
+Tenés la ligadura al ámbito de la petición dentro de:
+
+* bloques pasados a get/head/post/put/delete/options
+* filtros before/after
+* métodos ayudantes
+* plantillas/vistas
+
+=== Ámbito de Delegación
+
+El ámbito de delegación solo reenvía métodos al ámbito de clase. De cualquier
+manera, no se comporta 100% como el ámbito de clase porque no tenés la ligadura
+de la clase: únicamente métodos marcados explícitamente para delegación están
+disponibles y no compartís variables/estado con el ámbito de clase (léase:
+tenés un +self+ diferente). Podés agregar delegaciones de método llamando a
+<tt>Sinatra::Delegator.delegate :nombre_del_metodo</tt>.
+
+Tenés la ligadura al ámbito de delegación dentro de:
+
+* La ligadura del top-level, si hiciste <tt>require "sinatra"</tt>
+* Un objeto extendido con el mixin <tt>Sinatra::Delegator</tt>
+
+Pegale una mirada al código: acá está el
+{Sinatra::Delegator mixin}[http://github.com/sinatra/sinatra/blob/ceac46f0bc129a6e994a06100aa854f606fe5992/lib/sinatra/base.rb#L1128]
+que es {incluido en el espacio de nombres principal}[http://github.com/sinatra/sinatra/blob/ceac46f0bc129a6e994a06100aa854f606fe5992/lib/sinatra/main.rb#L28].
+
+== Línea de Comandos
+
+Las aplicaciones Sinatra pueden ser ejecutadas directamente:
+
+  ruby miapp.rb [-h] [-x] [-e ENTORNO] [-p PUERTO] [-o HOST] [-s MANEJADOR]
+
+Las opciones son:
+
+  -h # ayuda
+  -p # asigna el puerto (4567 es usado por defecto)
+  -o # asigna el host (0.0.0.0 es usado por defecto)
+  -e # asigna el entorno (development es usado por defecto)
+  -s # especifica el servidor/manejador rack (thin es usado por defecto)
+  -x # activa el mutex lock (está desactivado por defecto)
+
+== Versiones de Ruby Soportadas
+
+Las siguientes versiones de Ruby son soportadas oficialmente:
+
+[ Ruby 1.8.7 ]
+  1.8.7 es soportado completamente.  Sin embargo, si no hay nada que te lo
+  prohíba, te recomendamos que usés 1.9.2 o cambies a JRuby o Rubinius.  No se
+  dejará de dar soporte a 1.8.7 hasta Sinatra 2.0 y Ruby 2.0, aunque si se
+  libera la versión 1.8.8 de Ruby las cosas podrían llegar a cambiar.  Sin
+  embargo, que eso ocurra es muy poco probable, e incluso el caso de que lo
+  haga, puede que se siga dando soporte a 1.8.7.  <b>Hemos dejado de soportar
+  Ruby 1.8.6.</b> Si querés ejecutar Sinatra sobre 1.8.6, podés utilizar la
+  versión 1.2, pero tené en cuenta que una vez que Sinatra 1.4.0 sea liberado,
+  ya no se corregirán errores por más que se reciban reportes de los mismos.
+
+[ Ruby 1.9.2 ]
+  1.9.2 es soportado y recomendado.  Tené en cuenta que Radius y Markaby no son
+  compatibles con 1.9 actualmente.  Además, no usés 1.9.2p0, porque se producen
+  fallos de segmentación cuando se ejecuta Sinatra.  El soporte se mantendrá al
+  menos hasta que se libere la versión 1.9.4/2.0 de Ruby.  El soporte para la
+  última versión de la serie 1.9 se mantendrá mientras lo haga el core team de
+  Ruby.
+
+[ Ruby 1.9.3 ]
+  1.9.3 es soportado completamente.  De todas maneras, recomendamos esperar a
+  que se liberen niveles de parche superiores (el actual es p0) antes de usarlo
+  en producción.  Es importante notar que el cambio desde una versión anterior a
+  1.9.3 va a invalidar todas las sesiones.
+
+[ Rubinius ]
+  Rubinius es soportado oficialmente (Rubinius >= 1.2.4).  Todo funciona
+  correctamente, incluyendo los lenguajes de plantillas.  La próxima versión,
+  2.0, también es soportada.
+
+[ JRuby ]
+  JRuby es soportado oficialmente (JRuby >= 1.6.5).  No se conocen problemas
+  con librerías de plantillas de terceras partes.  Sin embargo, si elegís usar
+  JRuby, deberías examinar sus Rack handlers porque el servidor web Thin no es
+  soportado completamente.  El soporte de JRuby para extensiones C se encuentra
+  en una etapa experimental, sin embargo, de momento solamente RDiscount,
+  Redcarpet y RedCloth se ven afectadas.
+
+Siempre le prestamos atención a las nuevas versiones de Ruby.
+
+Las siguientes implementaciones de Ruby no se encuentran soportadas
+oficialmente.  De cualquier manera, pueden ejecutar Sinatra:
+
+* Versiones anteriores de JRuby y Rubinius
+* Ruby Enterprise Edition
+* MacRuby, Maglev e IronRuby
+* Ruby 1.9.0 y 1.9.1 (pero no te recomendamos que los usés)
+
+No estar soportada oficialmente, significa que si las cosas solamente se rompen
+ahí y no en una plataforma soportada, asumimos que no es nuestro problema sino
+el suyo.
+
+Nuestro servidor CI también se ejecuta sobre ruby-head (que será la próxima
+versión 2.0.0) y la rama 1.9.4.  Como están en movimiento constante, no podemos
+garantizar nada.  De todas formas, podés contar con que tanto 1.9.4-p0 como
+2.0.0-p0 sea soportadas.
+
+Sinatra debería funcionar en cualquier sistema operativo soportado por la
+implementación de Ruby elegida.
+
+En este momento, no vas a poder ejecutar Sinatra en Cardinal, SmallRuby,
+BlueRuby o cualquier versión de Ruby anterior a 1.8.7.
+
+== A la Vanguardia
+
+Si querés usar el código de Sinatra más reciente, sentite libre de ejecutar
+tu aplicación sobre la rama master, en general es bastante estable.
+
+También liberamos prereleases de vez en cuando, así, podés hacer
+
+  gem install sinatra --pre
+
+Para obtener algunas de las últimas características.
+
+=== Con Bundler
+
+Esta es la manera recomendada para ejecutar tu aplicación sobre la última
+versión de Sinatra usando {Bundler}[http://gembundler.com/].
+
+Primero, instalá bundler si no lo hiciste todavía:
+
+  gem install bundler
+
+Después, en el directorio de tu proyecto, creá un archivo +Gemfile+:
+
+  source :rubygems
+  gem 'sinatra', :git => "git://github.com/sinatra/sinatra.git"
+
+  # otras dependencias
+  gem 'haml'                    # por ejemplo, si usás haml
+  gem 'activerecord', '~> 3.0'  # quizás también necesités ActiveRecord 3.x
+
+Tené en cuenta que tenés que listar todas las dependencias directas de tu
+aplicación. No es necesario listar las dependencias de Sinatra (Rack y Tilt)
+porque Bundler las agrega directamente.
+
+Ahora podés arrancar tu aplicación así:
+
+  bundle exec ruby miapp.rb
+
+=== Con Git
+
+Cloná el repositorio localmente y ejecutá tu aplicación, asegurándote que el
+directorio <tt>sinatra/lib</tt> esté en el <tt>$LOAD_PATH</tt>:
+
+  cd miapp
+  git clone git://github.com/sinatra/sinatra.git
+  ruby -Isinatra/lib miapp.rb
+
+Para actualizar el código fuente de Sinatra en el futuro:
+
+  cd miapp/sinatra
+  git pull
+
+=== Instalación Global
+
+Podés construir la gem vos mismo:
+
+  git clone git://github.com/sinatra/sinatra.git
+  cd sinatra
+  rake sinatra.gemspec
+  rake install
+
+Si instalás tus gems como root, el último paso debería ser
+
+  sudo rake install
+
+== Versionado
+
+Sinatra utiliza el {Versionado Semántico}[http://semver.org/],
+siguiendo las especificaciones SemVer y SemVerTag.
+
+== Lecturas Recomendadas
+
+* {Sito web del proyecto}[http://www.sinatrarb.com/] - Documentación
+  adicional, noticias, y enlaces a otros recursos.
+* {Contribuyendo}[http://www.sinatrarb.com/contributing] - ¿Encontraste un
+  error?. ¿Necesitás ayuda?. ¿Tenés un parche?.
+* {Seguimiento de problemas}[http://github.com/sinatra/sinatra/issues]
+* {Twitter}[http://twitter.com/sinatra]
+* {Lista de Correo}[http://groups.google.com/group/sinatrarb/topics]
+* {IRC: #sinatra}[irc://chat.freenode.net/#sinatra] en http://freenode.net
+* {Sinatra Book}[http://sinatra-book.gittr.com] Tutorial (en inglés).
+* {Sinatra Recipes}[http://recipes.sinatrarb.com/] Recetas contribuidas
+  por la comunidad (en inglés).
+* Documentación de la API para la
+  {última versión liberada}[http://rubydoc.info/gems/sinatra] o para la
+  {rama de desarrollo actual}[http://rubydoc.info/github/sinatra/sinatra]
+  en http://rubydoc.info/
+* {Servidor de IC}[http://ci.rkh.im/view/Sinatra/]