README.es.md in sinatra-1.4.1 vs README.es.md in sinatra-1.4.2

- old
+ new

@@ -13,11 +13,11 @@ get '/' do 'Hola mundo!' end ``` -Instalá la gem y ejecutá la aplicación con: +Instalá el gem y corré la aplicación con: ``` shell gem install sinatra ruby miapp.rb ``` @@ -56,15 +56,15 @@ options '/' do .. informar algo .. end ``` -Las rutas son comparadas en el orden en el que son definidas. La primer ruta +Las rutas son comparadas en el orden en el que son definidas. La primera 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 `params`: +través del hash `params`: ``` ruby get '/hola/:nombre' do # coincide con "GET /hola/foo" y "GET /hola/bar" # params[:nombre] es 'foo' o 'bar' @@ -74,10 +74,13 @@ También podés acceder a los parámetros nombrados usando parámetros de bloque: ``` ruby get '/hola/:nombre' do |n| + # coincide con "GET /hola/foo" y "GET /hola/bar" + # params[:nombre] es 'foo' o 'bar' + # n almacena params[:nombre] "Hola #{n}!" end ``` Los patrones de ruta también pueden incluir parámetros splat (o wildcard), @@ -126,11 +129,11 @@ # 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 *path +A propósito, a menos que desactives la protección para el ataque *path traversal* (ver más abajo), el path de la petición puede ser modificado antes de que se compare con los de tus rutas. ## Condiciones @@ -199,14 +202,14 @@ end ``` ### Valores de Retorno -El valor de retorno de un bloque de ruta determina al menos el cuerpo de la +El valor de retorno de un bloque de ruta que 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. +Sin embargo, otros valores 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: `[estado (Fixnum), cabeceras (Hash), cuerpo de @@ -375,11 +378,11 @@ <tt>settings.views</tt>. </dd> <dt>layout</dt> <dd> - Si es <tt>true</tt> o <tt>false</tt> indica que se debe usar, o nó, un layout, + Si es <tt>true</tt> o <tt>false</tt> indica que se debe usar, o no, un layout, respectivamente. También puede ser un símbolo que especifique qué plantilla usar. Ejemplo: <tt>erb :index, :layout => !request.xhr?</tt> </dd> <dt>content_type</dt> @@ -410,13 +413,13 @@ </dd> <dd> 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. + tenés que usar: `:'subdir/plantilla'` o `'subdir/plantilla'.to_sym`). 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. </dd> </dl> ### Lenguajes de Plantillas Disponibles @@ -870,11 +873,10 @@ </tt> </td> </tr> </table> - El contenido de La plantilla se evalúa como código Ruby, y la variable `json` es convertida a JSON mediante `#to_json`. ``` ruby json = { :foo => 'bar' } json[:baz] = key @@ -1055,11 +1057,11 @@ after do puts response.status end ``` -Nota: A menos que usés el método `body` en lugar de simplemente devolver un +Nota: A menos que uses 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 @@ -1123,11 +1125,11 @@ incluir los módulos en la clase de la aplicación. ### 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: +Cuando están activadas, proporciona un hash de sesión para cada sesión de usuario: ``` ruby enable :sessions get '/' do @@ -1138,12 +1140,12 @@ session[:valor] = params[:valor] end ``` Tené en cuenta que `enable :sessions` 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 +cookie, lo cual no es siempre deseable (guardar muchos datos va a incrementar +el 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 `enable :sessions`: ``` ruby use Rack::Session::Pool, :expire_after => 2592000 @@ -1228,11 +1230,11 @@ '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. +siguiente ruta que coincida. Si no coincide ninguna ruta, se devuelve 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`: @@ -1411,11 +1413,11 @@ %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 +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`: @@ -1522,11 +1524,11 @@ 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á +de cacheo con proxys reversos, mirá [rack-cache](https://github.com/rtomayko/rack-cache): ``` ruby require "rack/cache" require "sinatra" @@ -1546,11 +1548,11 @@ 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 `*` 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 +(como post) asume que no. Podes cambiar este comportamiento con la opción `:new_resource`: ``` ruby get '/crear' do etag '', :new_resource => true @@ -1641,11 +1643,11 @@ 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) + request.forwarded? # true (si se está corriendo atrás de un proxy reverso) requuest.env # hash de entorno directamente entregado por Rack end ``` Algunas opciones, como `script_name` o `path_info` pueden @@ -1764,11 +1766,11 @@ super(folder, name, engine, &block) end end ``` -¡Es muy fácil convertir estos ejemplos en una extensión y compartirla!. +¡Es muy fácil convertir estos ejemplos en una extensión y compartirla! Notá que `find_template` 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 @@ -1862,11 +1864,11 @@ 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 + reverso que no se ha configurado adecuadamente. Notá que el helper <tt>url</tt> va a seguir produciendo URLs absolutas, a menos que le pasés <tt>false</tt> como segundo parámetro. Deshabilitada por defecto. </dd> @@ -1994,11 +1996,11 @@ </dd> <dt>run</dt> <dd> Cuando está habilitada, Sinatra se va a encargar de - iniciar el servidor web, no la habilités cuando estés + iniciar el servidor web, no la habilites cuando estés usando rackup o algún otro medio. </dd> <dt>running</dt> <dd> @@ -2031,11 +2033,11 @@ <dt>static</dt> <dd> Define si Sinatra debe encargarse de servir archivos estáticos. - Deshabilitala cuando usés un servidor capaz de + Deshabilitala cuando uses 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. </dd> @@ -2154,11 +2156,11 @@ ## 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 +características 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 @@ -2174,13 +2176,13 @@ get '/hola' do 'Hola Mundo' end ``` -Las semánticas de `use` son idénticas a las definidas para el DSL +La semántica de `use` es idéntica a la definida 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` +frecuentemente usado en archivos rackup). Por ejemplo, el método `use` acepta argumentos múltiples/variables así como bloques: ``` ruby use Rack::Auth::Basic do |nombre_de_usuario, password| nombre_de_usuario == 'admin' && password == 'secreto' @@ -2235,11 +2237,11 @@ ## 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 +reutilizables como Rack middleware, Rails metal, librerías simples con un componente de servidor, o incluso extensiones de Sinatra. El DSL de top-level asume una configuración apropiada para micro-aplicaciones (por ejemplo, un único archivo de aplicación, los directorios `./public` y `./views`, logging, página con detalles de excepción, etc.). Ahí es donde `Sinatra::Base` entra en el juego: @@ -2572,11 +2574,11 @@ Tenés la ligadura al ámbito de delegación dentro de: * La ligadura del top-level, si hiciste `require "sinatra"` * Un objeto extendido con el mixin `Sinatra::Delegator` -Pegale una mirada al código: acá está el +Hechale un vistazo al código: acá está el [Sinatra::Delegator mixin](https://github.com/sinatra/sinatra/blob/ca06364/lib/sinatra/base.rb#L1609-1633) que [extiende el objeto main](https://github.com/sinatra/sinatra/blob/ca06364/lib/sinatra/main.rb#L28-30). ## Línea de Comandos @@ -2603,11 +2605,11 @@ <dl> <dt>Ruby 1.8.7</dt> <dd> 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 + prohiba, te recomendamos que uses 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 @@ -2615,11 +2617,11 @@ ya no se corregirán errores por más que se reciban reportes de los mismos. </dd> <dt>Ruby 1.9.2</dt> <dd> - 1.9.2 es soportado y recomendado. No usés 1.9.2p0, porque se producen fallos + 1.9.2 es soportado y recomendado. No uses 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. </dd> @@ -2653,20 +2655,20 @@ 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) +* Ruby 1.9.0 y 1.9.1 (pero no te recomendamos que los uses) 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 +versión 2.1.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. +2.1.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, @@ -2675,10 +2677,10 @@ ## 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 +También liberamos prereleases de vez en cuando, así, podés hacer: ``` shell gem install sinatra --pre ```