kotovalexarian-likes-github
/
sinatra
mirror of https://github.com/sinatra/sinatra
1
0
Fork 0
Code Releases Activity

doc we no longer extend all objects in README.es

This commit is contained in:
Gabriel Andretta 2011-12-31 14:22:43 -03:00
parent 71b0e040be
commit 6fab02c6d3
1 changed files with 11 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
README.es.rdoc
View File

@ -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 <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:
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'
@ -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