From 6fab02c6d381648da473431050aa632afb2e32c4 Mon Sep 17 00:00:00 2001 From: Gabriel Andretta Date: Sat, 31 Dec 2011 14:22:43 -0300 Subject: [PATCH] doc we no longer extend all objects in README.es --- README.es.rdoc | 28 +++++++++++----------------- 1 file changed, 11 insertions(+), 17 deletions(-) diff --git a/README.es.rdoc b/README.es.rdoc index 86b74959..885fa5b7 100644 --- a/README.es.rdoc +++ b/README.es.rdoc @@ -1607,10 +1607,10 @@ 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 ./public y ./views, logging, página con detalles -de excepción, etc.). Ahí es donde Sinatra::Base entra en el juego: +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: require 'sinatra/base' @@ -1644,20 +1644,14 @@ para detalles sobre las opciones disponibles y su comportamiento. 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: +Las desventaja de usar el estilo clásico en lugar del modular consiste en que +solamente podés tener una aplicación Sinatra por proceso Ruby. Si tenés +planificado usar más, cambiá al estilo modular. Al mismo tiempo, tené en +cuenta que no hay ninguna razón por la cuál no puedas mezclar los estilos +clásico y 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: +A continuación se detallan las diferencias (sutiles) entre las configuraciones +de ambos estilos: Configuración Clásica Modular