diff --git a/book-content/es/2-getting-started/1-install-instructions.markdown b/book-content/es/2-getting-started/1-install-instructions.markdown index b2bf357a..4a66d4bc 100644 --- a/book-content/es/2-getting-started/1-install-instructions.markdown +++ b/book-content/es/2-getting-started/1-install-instructions.markdown @@ -1,29 +1,31 @@ -# Comenzando +# Comenzando a trabajar * Esto será una tabla de contenidos (este texto será pegado). {:toc} -Necesitaremos instalar Merb para usar la plataforma. -Claro, antes de que instalemos Merb necesitarás tener instalado un compilador C, Ruby y -[RubyGems][], y una base de datos (si quieres hacer tus modelos persistentes). +Se necesita instalar Merb para usar la plataforma. +De todas maneras, antes de instalar Merb, +usted necesitará tener instalado un compilador C, Ruby y [RubyGems][], +y una base de datos (si usted desea hacer sus modelos persistentes). ## OS X ### Prerequisitos -Necesitarás instalar XCode del CD OS X o descargarle del +Necesitará instalar XCode (conocido como las Herramientas de Desarrollo) +del DVD del sistema operativo OS X o descargarlo directamente del [sitio web para desarrolladores de Apple][]. ### Ruby & RubyGems -Si tienes OS X 10.5 (Leopard), es muy probable que tengas ya Ruby instalado. +En el caso que usted tenga instalado en su sistema OS X 10.5 (Leopard), +entonces su sistema ya cuenta con Ruby instalado y listo para su uso. ### Merb $ sudo gem install merb - ## Linux -Las siguientes instrucciones son para distribuciones basadas en Debian ([Ubuntu][], por -ejemplo) que usen el manejador de paquetes apt-get. -Si estás usando una distribución diferente, usa el manejador de paquetes de tu distribución +Las siguientes instrucciones son para aquellas distribuciones basadas en [Debian][] +([Ubuntu][], por ejemplo) que usen el manejador de paquetes apt-get. +Si usted utiliza una distribución diferente, use el manejador de paquetes de su distribución (por ejemplo, los sistemas [RedHat][] usan yum como su manejador de paquetes). ### Prerequisitos @@ -45,41 +47,42 @@ Si estás usando una distribución diferente, usa el manejador de paquetes de tu $ sudo ln -s /usr/bin/gem1.8 /usr/bin/gem $ sudo gem update --system - ### Merb $ sudo gem install merb - ## Windows Los usuarios de Windows tienen un par de opciones para instalar Ruby and RubyGems. Una manera es descargar los binarios de Ruby, instalarlos, y luego instalar RubyGems. -Una alternativa es usar el [One-Click Ruby Installer][] que viene empaquetado con RubyGems -(y algunas otras cosas). -Si usas el One-Click Installer, asegúrate de seleccionar la opción 'Enable RubyGems' en el -wizard de instalación. +Una alternativa es usar el [One-Click Ruby Installer][] +que viene empaquetado con RubyGems (y algunas otras cosas). +Si usted utiliza el One-Click Installer, +asegúrese de seleccionar la opción 'Enable RubyGems' durante la instalación. -Por defecto te instalará Ruby en el directorio C:\Ruby. -Una vez instalado, has lo siguiente: +Por defecto, Ruby se instalara en el directorio C:\Ruby. +Una vez instalado, usted debe hacer lo siguiente: Start --> Programs --> Ruby-<version> --> RubyGems --> RubyGems Package Manager -Esto abrirá un prompt de comando en el directorio C:\Ruby y mostrará alguna -información sobre cómo usar. Entonces es solo a cuestión de instalar Merb: +Esto abrirá un prompt de comando en el directorio C:\Ruby +y mostrará alguna información sobre cómo usarlo. +Entonces es solo a cuestión de instalar Merb: C:\Ruby> gem install merb -Este comando puede demorar unos minutos en ejecutarse, pues debe actualizar la cache de -las gemas, traer todas las gemas relacionadas con Merb e instalarlas. +Este comando puede demorar unos minutos en ejecutarse, +pues debe actualizar la cache de las gemas, +traer todas las gemas relacionadas con Merb e instalarlas. -_Nota_: Si quieres usar una base de datos SQLite (es la que viene por defecto), tienes que -descargarla e instalarla por separado. Más información puede ser encontrada en el sitio de -[SQLite][]. +_Nota_: Si desea usar una base de datos SQLite (la cual viene por defecto), +usted debe descargarla e instalarla por separado. +Más información puede ser encontrada en el sitio de [SQLite][]. [sitio web para desarrolladores de Apple]: http://developer.apple.com/technology/xcode.html -[RubyGems]: http://www.rubygems.org/ -[Ubuntu]: http://www.ubuntu.com/ -[RedHat]: http://www.redhat.com/ +[Debian]: http://www.debian.org/ +[RubyGems]: http://www.rubygems.org/ +[Ubuntu]: http://www.ubuntu.com/ +[RedHat]: http://www.redhat.com/ [One-Click Ruby Installer]: http://rubyinstaller.rubyforge.org/wiki/wiki.pl -[SQLite]: http://www.sqlite.org/ +[SQLite]: http://www.sqlite.org/ diff --git a/book-content/es/2-getting-started/2-generate-an-application.markdown b/book-content/es/2-getting-started/2-generate-an-application.markdown index 599b4e05..61bdfd6a 100644 --- a/book-content/es/2-getting-started/2-generate-an-application.markdown +++ b/book-content/es/2-getting-started/2-generate-an-application.markdown @@ -3,83 +3,92 @@ * Esto será una tabla de contenidos (este texto será pegado). {:toc} -Merb viene con un generador (merb-gen) para crear aplicaciones Merb. El generador -puede generar diferentes tipos aplicaciones Merb, para ver todas las opciones del generador -usa +Merb viene con un generador (``merb-gen``) +para crear aplicaciones. +Este generador puede crear diferentes tipos aplicaciones; +para ver todas las opciones del mismo, +escriba en la linea de comandos - $ merb-gen -h + $ merb-gen -H +{:lang=shell html_use_syntax=true} -Por ahora, limitémonos solamente a los tipos de aplicaciones Merb que se pueden generar. +Por ahora, limitémonos solamente a los tipos de aplicaciones Merb +que pueden ser generadas a través del mismo. ## Tipos Merb puede ser usado para desarrollar desde aplicaciones consistentes en un solo archivo, muy pequeñas y rápidas hasta grandes y complejos web services. Diferentes estructuras para la aplicación pueden generarse, dependiendo de las necesidades del desarrollador. - -Las diferentes estructuras para la aplicación que puedes generar son app para una -stack, core para un núcleo, flat para aplicaciones planas, y -very_flat para aplicaciones muy planas. +Las diferentes estructuras que usted puede generar +son ``app``, ``core``, ``flat`` y ``very_flat``. ### App (stack) El stack dogmático de Merb. -Esto genera una estructura de directorios completa para la aplicación con un conjunto -completo de archivos de configuración. -También adiciona un archivo config/dependancies.rb que incluye todo el -merb-more y DataMapper. +Esta opción genera una estructura de directorios completa para una aplicación +con un conjunto completo de archivos de configuración. +También agrega el archivo ``config/dependancies.rb`` +que incluye las todas las librerías contenidas en ``merb-more`` y ``DataMapper``. $ merb-gen app my-application +{:lang=shell html_use_syntax=true} -Esta aplicación tiene todo lo necesario para comenzar a construir una aplicación web -completa; es la más similar a la estructura típica de Rails. -Mucho en este libro funcionará con la suposición de que has comenzado de esta manera. +Esta aplicación contiene todo lo necesario +para comenzar a construir una aplicación web de primer nivel; +la cual es muy similar a la estructura típica de una aplicación Rails. +Este libro parte de la suposición +de que usted ha comenzado a desarrollar una aplicación de este tipo. -Arranca esta aplicación ejecutando merb en el directorio raiz de la aplicación. +Inicie esta aplicación ejecutando ``merb`` +en el directorio raíz de la aplicación. Esto iniciará Merb y lo pondrá a escuchar en el puerto por defecto 4000. -Para ver tu aplicación en acción, visita [http://localhost:4000/][]. +Para ver su aplicación en acción, +visita en su navegador web. ### Core (núcleo) -Core generará una estructura de directorios completa para la aplicación con un conjunto -completo de archivos de configuración. -A diferencia de app -- la stack completa dogmática -- ninguna dependencia se -adicionará. +Core generará una estructura de directorios completa para una aplicación +con un conjunto completo de archivos de configuración. +A diferencia de la opción ``app`` -- el stack dogmática y completo -- +ninguna dependencia será agregada a la aplicación. - $ merb-gen core my-apliccation + $ merb-gen core my-application +{:lang=shell html_use_syntax=true} -Arranca esta aplicación ejecutando merb en el directorio raiz de la aplicación. -Fíjate que, a diferencia de las otras tres aplicaciones generadas, en core no existe -contenido por defecto. -Visitando [http://localhost:4000/][] generará un error hasta que adiciones contenido y -ruteo. +Inicie esta aplicación ejecutando ``merb`` +en el directorio raíz de la aplicación. +Fíjese que, a diferencia de las otras tres aplicaciones generadas, +en core no existe contenido por defecto definido. +Visitando en su navegador web +generará un error hasta que adicione contenido y lo enrute. ### Flat (plana) -Una aplicación plana mantiene toda su lógica en un solo archivo, pero tiene archivos -separados para configuración y un directorio propio para las vistas. +Una aplicación plana mantiene toda su lógica en un solo archivo, +pero tiene archivos de configuración separados y un directorio propio para las vistas. $ merb-gen flat my-application +{:lang=shell html_use_syntax=true} -Las aplicaciones planas son arrancadas, como cualquier otra aplicación merb generada, -ejecutando merb en el directorio raiz de la aplicación. -Por defecto, todos los métodos en la clase my-application serán tratados como -acciones con my-application como el controlador. e.g.: -[http://localhost:4000/my-application/foo][] +Este tipo de aplicación se inicializa, como cualquier otra aplicación generada por Merb, +ejecutando ``merb`` en el directorio raíz de la aplicación. +Por defecto, todos los métodos en la clase ``my-application`` +serán tratados como acciones con ``my-application`` como el controlador. +Por ejemplo: -Esto invocará MyApplication#foo y mostrará la salida desde la plantilla -foo.html.*. +Esto invocará ``MyApplication#foo`` +y creará la salida desde la plantilla ``foo.html.*``. ### Very Flat (muy plana) -A aplicación muy plana es similar a otros micro frameworks de Ruby, donde la aplicación -completa esta en un solo archivo. +Este tipo de aplicación es similar a otros micro plataformas de Ruby, +donde la aplicación completa se ubica en un solo archivo. $ merb-gen very_flat my-applcation +{:lang=shell html_use_syntax=true} -Para arrancar una aplicación muy plana, inicia Merb con el siguiente comando (en el -directorio de tu aplicación): - - $ merb -I my-applcation.rb +Para ejecutar una aplicación muy plana, inicia Merb con el siguiente comando +(en el directorio de tu aplicación): -Esto arrancará Merb y lo pondrá a escuchar en el puerto por defecto (4000). Para ver tu -aplicación en accionn, visita [http://localhost:4000/][]. + $ merb -I my-application.rb +{:lang=shell html_use_syntax=true} -[http://localhost:4000/]: http://localhost:4000/ -[http://localhost:4000/my-application/foo]: http://localhost:4000/my-application/foo +Esto arrancará Merb y lo pondrá a escuchar en el puerto por defecto (4000). +Para ver tu aplicación en acción, visita en su navegador web. diff --git a/book-content/es/2-getting-started/3-project-structure.markdown b/book-content/es/2-getting-started/3-project-structure.markdown index 0f1422bc..c34d7101 100644 --- a/book-content/es/2-getting-started/3-project-structure.markdown +++ b/book-content/es/2-getting-started/3-project-structure.markdown @@ -3,8 +3,8 @@ * Esto será una tabla de contenidos (este texto será pegado). {:toc} -La estructura típica de una aplicación Merb nueva (generada con merb-gen app) -lucirá más o menos así: +La estructura típica de una nueva aplicación Merb (generada con el comando ``merb-gen app``) +es definida más o menos así: Directorio de la aplicación (Merb.root) - app @@ -27,102 +27,115 @@ lucirá más o menos así: - spec - tasks -Hagamos un breve resumen de cada directorio y su función. +A continuación se presentará una síntesis de cada directorio y su función especifica. ## app -Este directorio es donde emplearás la mayor parte de tu tiempo, dado que contiene las -"entrañas" de tu aplicación Merb. +Este directorio es donde usted empleará la mayor parte de su tiempo, +dado que contiene las "entrañas" de su aplicación Merb. ### controllers -Todos los controladores de tu aplicación son almacenados aquí (esto no supone sorpresa). -Los controladores son típicamente nombrados en plural. -Por ejemplo, si tienes un modelo "Page", el archivo del controlador normalmente se -llamará pages.rb. -Esto es simplemente una convención, al fin y al cabo; tu eres libre de nombrar tus -controladores como más te guste. -Visita la sección [controladores][] para más información. +Todos los controladores de su aplicación son almacenados aquí (lo cual no supone sorpresa alguna). +Los controladores son generalmente nombrados en plural. +Por ejemplo, si tiene un modelo llamado "``Pagina``", +entonces el archivo del controlador debería de llamarse ``paginas.rb``. +Esto es simplemente una convención, de todas maneras; +usted es libre de nombrar sus controladores a su conveniencia. +Visite la sección [controladores][] para más información. ### models -Este directorio contiene las clases de tus modelos. -Estas clases típicamente sirven como tu [ORM][], que proveen acceso orientado a objecto a -tus tablas en la base de datos. -Visita la sección [modelos][] para más información. +Este directorio contiene las clases de sus modelos. +Estas clases típicamente sirven como su [ORM][], +que proveen acceso orientado a objeto a sus tablas en la base de datos. +Visite la sección [modelos][] para más información. ### views -Cualquier plantilla para las vistas se almacenarán aquí. -Por defecto, este directorio contiene los subdirectorios exceptions y -layout. -El directorio exceptions almacena plantillas que están generalmente relacionadas a -errores HTTP. -Por ejemplo, una aplicación Merb nueva contendrá una vista -not_found.html.{erb,haml}, que corresponde al código de estado 404 de HTTP. -El directorio layout contiene las plantillas sobretodo de la aplicación, dentro de -las que las plantillas de las acciones pueden ser mostradas. -El archivo layout por defecto de la aplicación se llama -application.html.{erb,haml}. -Visita la sección [vistas][] para más información. +Cualquier plantilla para las vistas serán almacenadas aquí. +Por defecto, este directorio contiene los +subdirectorios ``exceptions`` y ``layout``. +El primero almacenará plantillas +que están generalmente relacionadas a errores HTTP. +Por ejemplo, una nueva aplicación Merb +contendrá la vista ``not_found.html.{erb,haml}``, +que corresponde al código de estado 404 de HTTP. +El ultimo contendrá las plantillas de la aplicación, +dentro de las cuales solamente las plantillas de las acciones serán mostradas. +El archivo de presentación por defecto de la aplicación +se llama ``application.html.{erb,haml}``. +Visite la sección [vistas][] para más información. ## config Si, lo adivinaste. -Los archivos de configuration de Merb son guardados aquí. -El archivo router.rb contiene las [rutas](/getting-started/router) URL de tu aplicación, que definen la estructura, ordednr, y apariencia de tus URLs. -Otro archivo importante, init.rb, se encarga de la configuration base de Merb. -Aquí es donde puedes configurar tu ORM, motor de plantillas, y plataforma de pruebas. -También puedes adicionar configuraciones a medida al Merb::BootLoader en sus bloques before_app_loads y after_app_loads. -Otro archivo importante, dependencies.rb, es donde puedes defindire las dependencias de tu aplicación: otras librarias o gemas que tu aplicación requiere. -Cualquire dependencia listada en ese archivo será cargada cuando tu aplicación Merb arranca. +Los archivos de configuración de Merb son almacenados aquí. +El archivo ``router.rb`` contiene las [rutas][] URL de su aplicación, +que definen la estructura, el orden y la apariencia de sus URLs. +Otro archivo importante, ``init.rb``, se encarga de la configuración base de Merb. +Aquí es donde puedes configurar su [ORM][], motor de plantillas, y plataforma de pruebas. +También puede adicionar configuraciones a medida en el ``Merb::BootLoader`` +en sus bloques ``before_app_loads`` y ``after_app_loads``. +Otro archivo importante, ``dependencies.rb``, +es donde usted puede definir las dependencias de su aplicación: +otras librerías o gemas que su aplicación requiere. +Cualquier dependencia listada en ese archivo será cargada cuando su aplicación Merb arranque. ### environments -Aquí es donde cualquier archivo de configuración específico a algun entorno son guardados. -Aquí existen un par de archivos típicos de configuración (en Ruby puro); cada uno corresponde a un entorno (desarrollo, producción, etc.) específico de Merb. +Aquí es donde todo archivo de configuración específico a algún entorno es guardado. +Existen un par de archivos típicos de configuración (en Ruby puro); +cada uno corresponde a un entorno especifico de Merb +(desarrollo, producción, etc.). ## gems -Cuando estés listo para [desplegar][] tu aplicación, es recomendable que -[empaquetes][] todos tus dependencias dentro del directorio de la aplicación. -El directorio gems es donde estas dependencias empaquetadas serán almacenadas. -Cuando inicies la aplicación Merb, esta cargará cualquier gema desde este directorio, priorizándolas a las gemas del sistema. +Cuando usted esté listo para el [despliegue][] su aplicación, +es recomendable que [empaquete][] todas sus dependencias +dentro del directorio de la aplicación. +El directorio ``gems`` es donde estas dependencias empaquetadas +serán almacenadas. +Cuando inicie su aplicación, +Merb cargará cada gema guardada en este directorio, otorgandoles prioridad por sobre las gemas del sistema. ## public -Aquí es donde puedes almacenar archivos "estáticos", tales como los archivos favicon.ico y robots.txt. +Aquí es donde usted puede almacenar los archivos "estáticos", +tales como ``favicon.ico`` y ``robots.txt``. ### images -Cualquier imagen que tus plantillas pueden usar deberán ir aquí. +Cualquier imagen que sus plantillas utilicen deberán ser almacenadas aquí. ### javascripts -En la "Merb stack" típica, este directorio contiene dos archivos: application.js y jquery.js. -La Merb stack por defecto viene empaquetada con la poderosa plataforma JavaScript -[jQuery][]. +En el típico "stack", este directorio contiene dos archivos: +``application.js`` y ``jquery.js``. +El stack por defecto viene empaquetado +con la poderosa plataforma JavaScript llamada [jQuery][]. -Si tienes cantidades pequeñas de código JavaScript específico a tu aplicación, deberá ir -dentro del archivo application.js. -Si resulta que esto se demuestra inviable, puedes adicionar más archivos según necesites. +Si usted tiene pequeñas cantidades de código JavaScript específico a su aplicación, +entonces resulta apropiado incluirlo dentro del archivo ``application.js``. +Si esto no es posible, entonces puede adicionar más archivos según sus necesidades. ### stylesheets -Siguiendo la idea de la separación de intereses, cualquier estilismo visual deberá ser -puesto en una hoja de estilos. -Cuando generás una aplicación Merb, se crea un archivo de hoja de estilos (llamado -master.css), que puedes ajustar a tus deseos. +Siguiendo la idea de la separación de intereses, +cualquier estilismo visual deberá ser definido en una hoja de estilos. +Cuando usted genera una aplicación Merb, +el generador crea un archivo de hoja de estilos (llamado ``master.css``), +el cual usted puede ajustar según sus necesidades. ## spec -Si estás usando [rspec][] como tu plataforma de [pruebas][], este directorio contendrá estos -tests. -Por defecto, este directorio contiene dos archivos: un archivo spec.opts vacio, qu - puedes usara para adicionar argumentos por linea de comandos a rspec (añadir salida -coloreada, etc.) y spec_helper.rb, que es donde puedes ajustar a conveniencia el -spec runner que utilices (entre otras cosas). +Si estás usando [RSpec][] como tu plataforma de [pruebas][], +este directorio contendrá todos los archivos de pruebas. +Por defecto, este directorio contiene dos archivos: +el archivo ``spec.opts`` vacío, +el cual usted puede usar para adicionar argumentos por linea de comandos a RSpec +(añadir salida coloreada, etc.) y ``spec_helper.rb``, +el cual usted puede ajustar a conveniencia el spec runner que utilice (entre otras cosas). ## tasks -Este directorio contiene las tareas de [thor][] de Merb. - - -[empaquetar]: /deployment/bundle -[controladores]: /getting-started/controllers -[desplegar]: /deployment -[jQuery]: http://jquery.com/ -[modelos]: /getting-started/models -[ORM]: http://en.wikipedia.org/wiki/Object-relational_mapping -[rutas]: /getting-started/router -[RSpec]: http://rspec.info/ -[probando]: /testing-your-application -[thor]: http://wiki.merbivore.com/faqs/thor -[vistas]: /getting-started/views +Este directorio almacenará las tareas [thor][] de Merb. + +[empaquete]: /deployment/bundle +[controladores]: /getting-started/controllers +[despliegue]: /deployment +[jQuery]: http://jquery.com/ +[modelos]: /getting-started/models +[ORM]: http://en.wikipedia.org/wiki/Object-relational_mapping +[rutas]: /getting-started/router +[RSpec]: http://rspec.info/ +[prueba]: /testing-your-application +[thor]: http://wiki.merbivore.com/faqs/thor +[vistas]: /getting-started/views diff --git a/book-content/es/2-getting-started/4-mvc.markdown b/book-content/es/2-getting-started/4-mvc.markdown index b16c28bf..482766b7 100644 --- a/book-content/es/2-getting-started/4-mvc.markdown +++ b/book-content/es/2-getting-started/4-mvc.markdown @@ -3,68 +3,66 @@ * Esto será una tabla de contenidos (este texto será pegado). {:toc} -MVC es un acrónimo que quiere decir Modelo, Vista, Controlador. -Describe una estructura de aplicaciones web que es fácil de mantener y -a la que es fácil hacer pruebas porque -separa la lógica de negocio, lógica de servidor y la generación de contenido. -Esta es la estructura de una aplicación standard Merb que es generada por el -comando '``merb-gen app``'. -Es esta también la estructura usada por [Rails][], [CakePHP][], [Django][], -y muchas otras plataformas de desarrollo web. +MVC es un acrónimo que significa "Modelo, Vista, Controlador". +Describe una manera de estructurar una aplicación web +que es fácil de probar y mantener +debido a que separa la lógica de negocio, lógica de servidor y la generación de contenido. +Esta es la estructura de una aplicación standard Merb +que es generada por el comando '``merb-gen app``'. +Es también la estructura adoptada por [Rails][], [CakePHP][], [Django][], +y muchas otras plataformas de desarrollo web populares. -Para desarrollar de manera efectiva en Merb -es importante que se comprenda tanto como funciona una estructura MVC, -como la manera más efectiva de trabajar con ella. -Este capítulo discutirá la plataforma someramente; -los siguientes tres capítulos examinarán cada parte en detalle. +Para desarrollar en Merb de una manera efectiva, +es sumamente importante que uno entienda tanto el funcionamiento de una estructura MVC +como la manera más apropiada de trabajar con ella. +Este capítulo discutirá la plataforma en forma general; +los siguientes tres capítulos examinarán cada pieza en detalle. Los [Modelos][] son el núcleo de la plataforma. -Ellos son responsables de la lógica de negocio de tu aplicación; -en Merb los Modelos son mayormente asociados con accesos a la base de datos +Ellos son los responsables de la lógica de negocio de su aplicación; +en Merb, son generalmente asociados con el acceso a la base de datos a través de un ORM tal como DataMapper o Active Record. -Algunas veces los Modelos son usados con un ORM, +Algunas veces los modelos son usados con un ORM, simplemente como un envoltorio para una tabla en la base de datos. -No obstante es generalmente considerado una buena práctica tener Modelos -'gordos'. -Esto significa que las clases Modelos es donde deberás mantener cosas +No obstante es generalmente considerado una buena práctica tener modelos 'gordos'. +Esto significa que usted debería mantener aspectos tales como relaciones de datos y métodos -para cada manipulación y recuperación no trivial de datos. +para cualquier pieza no trivial de recuperación y manipulación de datos +dentro de las clases modelos. -Las [Vistas][] son el ostentoso cascarón exterior de una aplicación. -Las Vistas son responsables de generar el contenido real (HTML, XML, JSON) +Las [Vistas][] son el ostentoso cascarón exterior de su aplicación. +Son las responsables de generar el contenido real (HTML, XML, JSON) retornado por una petición. -Muy tipicamente, las Vistas son escritas en un formato de plantillas +Generalmente, estas son escritas en un formato de plantillas tales como [Erb][] (Ruby embebido) o [Haml][]. -Los desarrolladores sabios intentarán poner tan poco código como sea posible en -sus Vistas. +Aquellos desarrolladores lo suficientemente sabios intentarán incluir tan poco +código como sea posible dentro sus vistas. Los [Controladores][] se encargan de recibir una petición entrante -y convertirla en una respuesta. +y de convertirla en una respuesta. Son responsables de interpretar la petición entrante, -obtener instancias de los Modelos necesarios, -y pasar esta información a la Vista. +obtener instancias de los modelos necesarios, +y pasar esta información a través de la vista. -En una aplicación Merb típica, -el código para cada una de estas partes se encuentra +En una típica aplicación Merb, +el código para todas estas tres partes se encuentra en directorios del mismo nombre dentro del directorio '``app``'. -En los siguientes capítulos examinaremos como Merb implementa cada una de estas -partes. +En los siguientes capítulos, examinaremos como Merb implementa cada una de estas partes. -Los usuarios principiantes se sienten muchas veces tentados a adicionar mucho -código en la capa de controladores, -pero esto conlleva a código frágil y difícil de probar. -En cambio se le recomienda a los desarrolladores -mantener sus controladores tan 'ligeros' como sea posible -poniendo el código que no está directamente relacionado con el ciclo -petición/respuesta (o la reunión de datos) en el Modelo. +Los principiantes suelen estar tentados por agregar +mucho código dentro de la capa de controladores, +que produce como consecuencia a un código frágil y difícil de probar. +En cambio, se recomienda a los desarrolladores +a mantener sus controladores tan 'ligeros' como sea posible +poniendo el código que no está directamente relacionado con el ciclo petición/respuesta +(o la reunión de datos) dentro del modelo. +[CakePHP]: http://www.cakephp.org/ +[Django]: http://www.djangoproject.com/ +[Rails]: http://rubyonrails.org +[Erb]: http://en.wikipedia.org/wiki/ERuby +[Haml]: http://haml.hamptoncatlin.com/ +[Controladores]: /getting-started/controllers +[Modelos]: /getting-started/models +[Vistas]: /getting-started/views - -[CakePHP]: http://www.cakephp.org/ -[Controladores]: /getting-started/controllers -[Django]: http://www.djangoproject.com/ -[Erb]: http://en.wikipedia.org/wiki/ERuby -[Haml]: http://haml.hamptoncatlin.com/ -[Modelos]: /getting-started/models -[Rails]: http://rubyonrails.org -[Vistas]: /getting-started/views diff --git a/book-content/es/2-getting-started/5-controllers.markdown b/book-content/es/2-getting-started/5-controllers.markdown index f7f0c92d..44a7e391 100644 --- a/book-content/es/2-getting-started/5-controllers.markdown +++ b/book-content/es/2-getting-started/5-controllers.markdown @@ -4,67 +4,64 @@ {:toc} > Un controlador es el enlace entre un usuario y el sistema. -> Provée al usuario con datos propiciando que las vistas relevantes -> se presenten ellas mismas en los lugares apropiados de la pantalla. -> Provée medios para ofrecer salida al usuario presentándole menús u otros -> medios de entrar comandos y datos. -> El controlador recibe tal salida del usuario, la traduce en los mensajes -> apropiados y pasa estos mensajes a una o más de las vistas. +> Este provee al usuario de una entrada arreglando que las vistas relevantes +> se presenten ellas mismas en los lugares apropiados de la pantalla. +> Ademas provee medios para la salida al usuario presentándole menús u otros +> medios para introducir comandos y datos. +> El controlador recibe tal salida al usuario, la traduce en mensajes +> apropiados y los redirecciona a una o más vistas. > - [Trygve Reenskaug][]{: .quote-author}, autor del patrón de diseño > Modelo-Vista-Controlador[^mvc-essay] {: cite=http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf .lead-quote} - En el paradigma [MVC][], los controladores representan la capa de pegamento -que conecta la lógica de negocio (Modelo) con las Vistas. +que conecta la lógica de negocio (definida dentro de un modelo) con las vistas. -Concretamente el controlador es responsable del mapeo de una acción del -usuario-final con una respuesta de la aplicación. +Concretamente, el controlador es responsable del realizar la interconexión entre +una acción del usuario con una respuesta definida en la aplicación. En Merb, técnicamente hablando, -los controladores son clases que heredan de ``Merb::Controller``. -En una aplicación Merb-stack, una clase controlador llamada ``Application`` es -creada. -Todos los controladores generados heredan de ``Application``; -por ende todos comparten los mismos atributos que ``Application``. +los controladores son clases que heredan su funcionalidad de la clase ``Merb::Controller``. +En una aplicación stack de Merb, una clase controlador llamada ``Application`` es creada. +Todos los controladores generados heredan de la clase recientemente mencionada; +por ende, todos ellos comparten los mismos atributos que la misma. La lógica del [Enrutador][] de Merb examina los detalles de la petición entrante, -comparándolos con reglas especificadas en el archivo ``router.rb``. -Asumiendo que una correspondencia es encontrada, -el Enrutador entonces envía la petición al controlador y acción apropiadas. +comparándolos contra las reglas especificadas en el archivo ``router.rb``. +Asumiendo que una correspondencia sea encontrada, +el enrutador entonces envía la petición al controlador y a la acción apropiadas. En este capítulo, veremos cómo generar y organizar los controladores. -También discutiremos cómo se pueden escribir **acciones**, -que son los métodos del controlador que son llamados para que se encarguen de -las peticiones entrantes. -Finalmente veremos cómo extender las funcionalidades de un controlador. +También discutiremos cómo escribir **acciones**, +que son los métodos de un controlador los cuales serán llamados +a la hora de manejar peticiones entrantes. +Finalmente, veremos cómo extender las funcionalidades de un controlador. ## Generando controladores -Tú puedes generar dos tipos de controladores: +Usted puede generar dos tipos de controladores: un controlador standard y un controlador [RESTful][]. ### Un controlador standard - $ merb-gen controller birds - [ADDED] app/controllers/birds.rb - [ADDED] app/views/birds/index.html.erb - [ADDED] spec/requests/birds_spec.rb - [ADDED] app/helpers/birds_helper.rb + $ merb-gen controller pajaros + [ADDED] app/controllers/pajaros.rb + [ADDED] app/views/pajaros/index.html.erb + [ADDED] spec/requests/pajaros_spec.rb + [ADDED] app/helpers/pajaros_helper.rb {:lang=shell html_use_syntax=true} El comando anterior genera varios archivos. -El archivo controlador (``birds.rb``) contendrá métodos para cada acción, +El archivo controlador (``pajaros.rb``) contendrá métodos para cada acción, así como otros métodos que el controlador necesita. El archivo plantilla de vista (``index.html.erb``) puede ser usado para generar HTML, usando un procesador de ``erb`` (Ruby embebido). -Los demás archivos (``birds_spec.rb``, ``birds_helper.rb``) -deben ser usados para almacenar las especificaciones de las pruebas así como -métodos helper (ayudantes). +Los archivos restantes (``pajaros_spec.rb``, ``pajaros_helper.rb``) +deben ser usados para contener las especificaciones de las pruebas así como los métodos de ayuda. -Echemos un vistazo rápido al controlador generado: +Si usted observa a simple vista el controlador generado: - class Birds < Application + class Pajaros < Application def index render @@ -73,170 +70,160 @@ Echemos un vistazo rápido al controlador generado: end {:lang=ruby html_use_syntax=true} -El generator adicionó una nueva clase llamada ``Birds``, -que hereda de ``Application``. -La nueva clase tiene un método llamado ``index``. +El generador agregó una nueva clase denominada ``Pajaros``, +que hereda su funcionalidad básica de la clase ``Application``. +Esta nueva clase contiene un método llamado ``index``. En el contexto de un controlador, -a menudo nos referimos a estos métodos como **acciones del controlador** o -simplemente **acciones**. - +a este tipo de métodos se los suele denominar +**acciones del controlador** o simplemente **acciones**. -``Application`` (una subclase de ``Merb::Controller``) -es la clase de la cual usualmente heredan los controladores. -Por ello es un lugar conveniente para compartir código entre controladores. +La clase ``Application`` (una subclase de ``Merb::Controller``) +es de la cual usualmente heredan los controladores. +Por esta razón, es conveniente utilizarla para compartir código entre controladores. (_usar con precaución_) - +-- {: .notes} -Si notas que cometiste un error generando tu controlador, -puedes borrar el controlador generado adicionando ``-d`` al -final del comando que recién enviaste: - - $ merb-gen controller birds -d - [DELETED] app/controllers/birds.rb - [DELETED] app/views/birds/index.html.erb - [DELETED] spec/requests/birds_spec.rb - [DELETED] app/helpers/birds_helper.rb +Si usted se da cuenta que ha cometido un error generando su controlador, +usted puede borrarlo agregando la opción ``-d`` al +final del comando que ha ejecutado: + + $ merb-gen controller pajaros -d + [DELETED] app/controllers/pajaros.rb + [DELETED] app/views/pajaros/index.html.erb + [DELETED] spec/requests/pajaros_spec.rb + [DELETED] app/helpers/pajaros_helper.rb {:lang=shell html_use_syntax=true} =-- ### Un controlador REStful - $ merb-gen resource_controller cats - [ADDED] spec/requests/cats_spec.rb - [ADDED] app/controllers/cats.rb - [ADDED] app/views/cats/index.html.erb - [ADDED] app/views/cats/show.html.erb - [ADDED] app/views/cats/edit.html.erb - [ADDED] app/views/cats/new.html.erb - [ADDED] app/helpers/cats_helper.rb + $ merb-gen resource_controller gatos + [ADDED] spec/requests/gatos_spec.rb + [ADDED] app/controllers/gatos.rb + [ADDED] app/views/gatos/index.html.erb + [ADDED] app/views/gatos/show.html.erb + [ADDED] app/views/gatos/edit.html.erb + [ADDED] app/views/gatos/new.html.erb + [ADDED] app/helpers/gatos_helper.rb {:lang=shell html_use_syntax=true} -Si abres el archivo controlador recién generado (``app/controllers/cats.rb``), -notarás que el generador creó un nueva clase llamada ``Cats``. -Como era de esperar la clase hereda de ``Application``. -Sin embargo, esta vez, en lugar de una acción ``index`` vacía, -encontramos siete acciones completamente definidas. +Si usted abre el archivo controlador recientemente generado (``app/controllers/gatos.rb``), +usted notará que el generador creó un nueva clase llamada ``Gatos``. +Como era de esperarse, la clase hereda su funcionalidad de la clase ``Application``. +Sin embargo, esta vez, en lugar de una acción ``index`` vacía, +se encontrara con siete acciones ya predefinidas. -Veamos el archivo generado: +Si usted observa a simple vista el archivo generado: - class Cats < Application + class Gatos < Application # provides :xml, :yaml, :js def index - @cats = Cat.all - display @cats + @gatos = Gato.all + display @gatos end def show(id) - @cat = Cat.get(id) - raise NotFound unless @cat - display @cat + @gato = Gato.get(id) + raise NotFound unless @gato + display @gato end def new only_provides :html - @cat = Cat.new - display @cat + @gato = Gato.new + display @gato end def edit(id) only_provides :html - @cat = Cat.get(id) - raise NotFound unless @cat - display @cat + @gato = Gato.get(id) + raise NotFound unless @gato + display @gato end - def create(cat) - @cat = Cat.new(cat) - if @cat.save - redirect resource(@cat), :message => {:notice => "Cat fue creado satisfactoriamente"} + def create(gato) + @gato = Gato.new(gato) + if @gato.save + redirect resource(@gato), :message => {:notice => "Gato fue creado exitosamente."} else - message[:error] = "Cat no pudo ser creado" + message[:error] = "Gato no pudo ser creado." render :new end end - def update(id, cat) - @cat = Cat.get(id) - raise NotFound unless @cat - if @cat.update_attributes(cat) - redirect resource(@cat) + def update(id, gato) + @gato = Gato.get(id) + raise NotFound unless @gato + if @gato.update_attributes(gato) + redirect resource(@gato) else - display @cat, :edit + display @gato, :edit end end def destroy(id) - @cat = Cat.get(id) - raise NotFound unless @cat - if @cat.destroy - redirect resource(:cats) + @gato = Gato.get(id) + raise NotFound unless @gato + if @gato.destroy + redirect resource(:gatos) else raise InternalServerError end end - end # Cats + end # Gatos {:lang=ruby html_use_syntax=true} - -Wow, eso es mucho código. Como regla general, -tú **no** debieras usar código generado que no entiendas. -Por suerte, el código anterior es muy fácil de entender -y nosotros lo repasaremos en detalle. +usted **no** debería utilizar código generado que no entienda. +Afortunadamente, el código detallado previamente es muy simple de comprender +y ahora procederemos a repasarlo en detalle. -Pero antes de que revisemos el código, hablemos sobre [REST][]. +Pero antes de revisarlo, es importante hablar sobre [REST][]. ## REST -[REST][] es un acrónimo para Transferencia de Estado Representacional -([Representational State Transfer][]). -Fue por primera vez introducido en el 2000 por [Roy Fielding][][^rest\_intro]. -REST se refiere a un estilo de arquitectura de software que esboza cómo los +[REST][] es el acrónimo que significa "Transferencia de Estado Representacional". +Fue por primera vez introducido en el año 2000 por [Roy Fielding][][^rest\_intro]. +REST se refiere a un estilo de arquitectura de software que delinea cómo los [recursos][] son definidos y accedidos. -De esta manera son los [recursos][] los componentes claves de REST. +Por consecuencia, los [recursos][] son los componentes claves de REST. -**¿Qué es un recurso, en el contexto de REST?** +**¿Qué es un recurso, dentro del contexto de REST?** Un recurso es una fuente de información específica, -referenciada por una URI (identificador global). -En términos no técnicos, es cierta información que puedes acceder a travez de una -dirección específica. +referenciada por una [URI][] (identificador global de recursos). +En términos prácticos, se trata de cierta información que puede +ser accedida a través de una dirección específica. REST usa el protocolo HTTP para comunicar datos entre los diferentes actores. -Es a menudo usado para servicios web, -porque sus principios aplican muy bien a recursos web. +Es generalmente utilizado para servicios web, +porque sus principios son aplicados coherentemente a los recursos web. -**Aquí está cómo es que la gente usualmente mapea recursos web REST:** +**Aquí se presenta cómo es realizada la interconexión de recursos web REST:** -**URI:** http://site.com/cats o http://site.com/cats/1-felix -(identificador/dirección global) - -**Formato:** Tipo o extensión MIME (HTML, JSON, XML, YAML, CSV, PDF, ...) - -**acción:** mapea los métodos HTTP (POST, GET, PUT, y DELETE) a métodos de recursos +**URI:** http://site.com/gatos o http://site.com/gatos/1-felix +(identificador global/dirección) +**Formato:** tipo o extensión MIME (HTML, JSON, XML, YAML, CSV, PDF, ...) +**Acción:** interconexión de los métodos HTTP (POST, GET, PUT, y DELETE) con los métodos de un recurso Si un recurso es definido, Merb usa la ``URI`` y el método HTTP para seleccionar un controlador y una acción. - - -[MVC]: /getting-started/mvc +[MVC]: /getting-started/mvc [redirect]: http://merbivore.com/documentation/1.0/doc/rdoc/merb-core-1.0/index.html?a=M000529&name=redirect -[Representational State Transfer]: http://en.wikipedia.org/wiki/Representational_State_Transfer -[recursos]: http://en.wikipedia.org/wiki/Representational_State_Transfer#REST.27s_central_principle:_resources -[REST]: http://en.wikipedia.org/wiki/Representational_State_Transfer -[RESTful]: http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_Web_services -[Enrutador]: /getting-started/router -[Roy Fielding]: http://en.wikipedia.org/wiki/Roy_Fielding] +[recursos]: http://en.wikipedia.org/wiki/Representational_State_Transfer#REST.27s_central_principle:_resources +[REST]: http://en.wikipedia.org/wiki/Representational_State_Transfer +[RESTful]: http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_Web_services +[Enrutador]: /getting-started/router +[Roy Fielding]: http://en.wikipedia.org/wiki/Roy_Fielding] [Trygve Reenskaug]: http://en.wikipedia.org/wiki/Trygve_Reenskaug -[View]: /getting-started/view +[View]: /getting-started/view +[URI]: ... - -[^rest\_intro]: Chapter 5 of Fielding’s dissertation is ["Representational State Transfer (REST)"](http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) -[^mvc-essay]: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf +[^rest\_intro]: Capitulo 5 de la disertación de Fielding sobre la ["Transferencia de Estados Representacionales (REST)"](http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) +[^mvc-essay]: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf - -*[HTTP]: Hypertext Transfer Protocolo -*[REST]: Representational state transfer +*[HTTP]: Hypertext Transfer Protocol +*[REST]: REpresentational State Transfer +*[URI]: Universal Resource Identifier diff --git a/book-content/es/2-getting-started/6-views.markdown b/book-content/es/2-getting-started/6-views.markdown index 53cf1709..c4f7f8fc 100644 --- a/book-content/es/2-getting-started/6-views.markdown +++ b/book-content/es/2-getting-started/6-views.markdown @@ -1,7 +1,8 @@ -#Views +# Vistas +* Esto será una tabla de contenidos (este texto será pegado). +{:toc} +## Ayudantes para Formularios -##Form Helpers - -##Date and Time Helpers \ No newline at end of file +## Ayudantes para Fecha y Tiempo \ No newline at end of file diff --git a/book-content/es/2-getting-started/7-models.markdown b/book-content/es/2-getting-started/7-models.markdown index 94980280..228ea63c 100644 --- a/book-content/es/2-getting-started/7-models.markdown +++ b/book-content/es/2-getting-started/7-models.markdown @@ -1,55 +1,52 @@ -#Modelos +# Modelos * Esto será una tabla de contenidos (este texto será pegado). {:toc} -Dicho a _grosso modo_ los modelos son la representación programática -de los conceptos y datos que una aplicación usa. -En una aplicación de blog, estos serían cosas -tales como artículos, comentarios y usuarios. -En una aplicación de tienda, -serían productos, clientes, carritos de compra, ventas, etc. -Merb fue diseñado para dar a los desarrolladores tanta libertad como fuera -posible describiendo sus modelos. -Los Modelos pueden ser cualquier cosa que un desarrollador pueda representar con -clases de Ruby. - -Dicho esto la gran mayoría de aplicaciones -usarán algún tipo de [ORM][] (Object Relational Mapper) -para hacer sus datos persistentes entre peticiones. -La mayoría de las aplicaciones almacenarán sus datos en alguna forma de base de -datos. -La Stack por defecto de Merb usa [DataMapper][] para comunicarse +Como ha sido argumentado, los modelos son la representación programática +de los conceptos y los datos que una aplicación utiliza. +En una aplicación de blog, estos modelos serían representaciones +de artículos, comentarios y usuarios. +En una aplicación de una tienda electrónica, +los modelos representarían productos, clientes, carritos de compra, ventas, etc. +Merb fue diseñado para dar a los desarrolladores tanta libertad como fuese posible +a la hora de describir sus modelos para una cierta aplicación. +Los modelos representaran cualquier cosa que un desarrollador pueda definir con clases de Ruby. + +Habiendo dicho esto, la gran mayoría de las aplicaciones +usarán algún tipo de [ORM][] (Interconexionador Relacional de Objetos) +para permitir que sus datos sean persistentes entre peticiones. +La mayoría de las aplicaciones almacenarán sus datos en alguna forma de base de datos. +El Stack por defecto de Merb utiliza [DataMapper][] para comunicarse con una base de datos [SQLite][]. -Esta es una excelente opción para desarrollar fácilmente proyectos nuevos. +Esta es una excelente opción para desarrollar fácilmente nuevos proyectos. -Sin embargo una vez en producción -es generalmente recomendado que los desarrolladores cambien -a alguno de los motores base de datos más potentes, +Una vez en producción, sin embargo, +es generalmente recomendado que los desarrolladores utilicen +alguno de los motores base de datos más potentes, tales como [PostgreSQL][] o [MySQL][]. -Proyectos que vengan del mundo de Rails -pueden querer mantener sus modelos [ActiveRecord][]; -Merb soporta esta elección también. +Para aquellos proyectos que provienen del mundo Rails +que deseen mantener sus modelos predefinidos en [ActiveRecord][]; +Merb también soporta esta librería para conectar a su base de datos. -El resto de este capítulo se enfocará en el uso de DataMapper -para crear clases Modelo. +El resto de este capítulo se enfocará en el uso de [DataMapper][] +para crear las clases modelo que su aplicación usará. ## Atributos -En un modelo de DataMapper, los atributos son definidos con el método ``property`` -Este método toma el nombre del atributo, un tipo de datos, -y un hash de opciones. -A diferencia de ActiveRecord, un modelo de DataMapper no requiere separar -archivos de migración (sin embargo las migraciones son soportadas). - -Aquí está un modelo de DataMapper standard bastante simple: +En un modelo de [DataMapper][], los atributos son definidos a través del método ``property``. +Este método toma el nombre de un atributo, su tipo de datos, +y una colección de opciones. +A diferencia de [ActiveRecord][], este tipo de modelo no requiere separar las migraciones +en archivos separados (aunque las migraciones sean soportadas por Merb). +A continuación se presentara un modelo standard [DataMapper][]: class Articulo include DataMapper::Resource - property :id, Serial - property :titulo, String - property :contenido, Text - property :publicado_el, DateTime + property :id, Serial + property :titulo, String + property :contenido, Text + property :fecha_publicacion, DateTime end {:lang=ruby html_use_syntax=true} @@ -57,59 +54,57 @@ Mira la sección de [propiedades][] del sitio de DataMapper para más detalles. ## Validaciones -Puedes hacer validaciones de los modelos de dos maneras diferentes. -Puedes definirlas al mismo tiempo que la definición del atributo -o usar explicitamente un método ``validates_*``. +Usted puede puede validar sus modelos en dos maneras posibles. +Ya sea definiendo las validaciones al mismo tiempo que la definición de un atributo +o utilizando explícitamente el método ``validates_*``. Los siguientes dos ejemplos son equivalentes: - # Usando "auto-validaciones", definidas con la propiedad. + # Utilizando "auto-validaciones", definidas con la propiedad. class Persona include DataMapper::Resource - property :id, Serial - property :nombre, String, :nullable => false - property :edad, Integer, :length => 1..150 + property :id, Serial + property :nombre, String, :nullable => false + property :edad, Integer, :length => 1..150 end # Usando los métodos "validates_*". class Persona include DataMapper::Resource - property :id, Serial + property :id, Serial property :nombre, String - property :edad, Integer + property :edad, Integer validates_present :nombre - validates_length :edad, :within => 1..150 + validates_length :edad, :within => 1..150 end {:lang=ruby html_use_syntax=true} -Para más information, mira la página de [validaciones][] de DataMapper. +Para más información, referirse a la página de [validaciones][] de DataMapper. ## Asociaciones -DataMapper tiene una manera muy versátil de definir asociaciones entre tus -modelos. -Todo tipo de asociaciones son soportadas, incluidos Uno-A-Muchos, -Muchos-A-Muchos, etc. +[DataMapper][] tiene una manera muy versátil de definir asociaciones entre sus modelos. +Todo tipo de asociaciones son soportadas, incluidas Uno-A-Muchos, Muchos-A-Muchos, etc. Las asociaciones son configuradas usando los métodos ``has`` y ``belongs_to``. -Digamos por ejemplo que estás escribiendp una aplicación de blog. -Esta aplicación tendrá los modelos Articulo y Comentario. -Aquí vemos como definimos la asociación: +En el caso, por ejemplo, que usted esta escribiendo una aplicación de blog. +Esta aplicación utilizará los modelos Articulo y Comentario. +A continuación le presentaremos como definir una asociación: class Articulo include DataMapper::Resource - # Estableciendo las propiedades. + # Definiendo las propiedades. has n, :comentarios end class Comentario include DataMapper::Resource - # Estableciendo las propiedades. + # Definiendo las propiedades. belongs_to :articulo end {:lang=ruby html_use_syntax=true} -Esto te brinda métodos para trabajar con las asociaciones. +[DataMapper][], ademas, proporciona métodos para trabajar con las asociaciones. articulo = Articulo.first articulo.comentarios # Devuelve todos los comentarios asociados. @@ -117,15 +112,15 @@ Esto te brinda métodos para trabajar con las asociaciones. comentario.articulo # Devuelve el Articulo padre. {:lang=ruby html_use_syntax=true} -Si miras el modelo Articulo, -notarás la "mítica, mágica ``n``". +Si usted observa el modelo Articulo previamente definido, +notará la "mítica y mágica ``n``". Este método es un atajo de ``Infinito`` -y es usado para proveer la asociación "tiene muchos" (has many). +y es utilizado para proveer la asociación "tiene muchos" (has many). Configurar una asociación "tiene uno" (has one) es tan simple como pasar el entero ``1`` (uno) al método ``has``. -For ejemplo: +Por ejemplo: class Persona include DataMapper::Resource @@ -141,29 +136,29 @@ For ejemplo: {:lang=ruby html_use_syntax=true} Como la asociación ``has many`` en Rails, -estas asociaciones provéen algunos métodos de ayuda (helper): +estas asociaciones proveen algunos métodos de ayuda: persona = Persona.first persona.taza_de_cafe # Devuelve la taza de la persona. taza = TazaDeCafe.first - taza.persona # Devuelve el dueño de la taza. + taza.persona # Devuelve el dueño de la taza. {:lang=ruby html_use_syntax=true} -Para ejemplos más complicados, tales como ``has many through`` (tiene muchos a -travez), refiérete a la página de DataMapper sobre [asociaciones][]. +Para observar ejemplos más complicados, tales como ``has many through`` (tiene muchos a través), +usted debe referirse a la página de DataMapper sobre [asociaciones][]. ## Callbacks -Los Callbacks te permiten "conectarte" a varios métodos, +Los Callbacks le permiten "engancharse" a varios métodos, para proveer funcionalidad adicional -o (por ejemplo) asegurar que una propiedad tiene cierto formato. -DataMapper soporta callbacks usando un enfoque [orientado a aspecto][] +o (por ejemplo) asegurar que una propiedad esta definida con un cierto formato. +[DataMapper][] soporta callbacks usando un enfoque [orientado a aspecto][] e incluye (entre otros) los métodos ``before`` y ``after``. -Digamos que tienes un modelo Comentario. -Quieres asegurar que la propiedad ``pagina_inicio`` comienza con "http://", -sin tener que exigir que la persona la provea explícitamente. -Esta es una manera de lograrlo: +En el caso de que usted tenga un modelo Comentario, por ejemplo. +Usted quiere asegurarse que la propiedad ``pagina_inicio`` comience con "http://", +sin tener que exigir que un usuario la provea explícitamente. +A continuación se le muestra una manera de implementar este requisito: class Comentario include DataMapper::Resource @@ -181,29 +176,27 @@ Esta es una manera de lograrlo: end {:lang=ruby html_use_syntax=true} -Como puedes ver, el método ``before`` toma (como símbolos) -el nombre del método al que te estás "conectando" +Como puede observar, el método ``before`` toma (traducidos como símbolos) +el nombre del método al que usted se está "enganchando" y el nombre del método que hará el trabajo. -puedes también pasar un bloque: +Usted también puede proporcionar un bloque: before :save do # ... el baile del mono. end {:lang=ruby html_use_syntax=true} -puedes definir callbacks para cualquier método, incluidos métodos de clase. -Para más detalles, refiérete a la página de DataMapper sobre [hooks][]. - - - -[ActiveRecord]: http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 +Usted puede definir callbacks para cualquier método, incluidos los métodos de una clase. +Para más detalles, por favor referirse a la página de DataMapper sobre [enganches][]. + +[ORM]: http://en.wikipedia.org/wiki/Object-relational_mapping +[ActiveRecord]: http://en.wikipedia.org/wiki/ActiveRecord_%28Rails%29 +[DataMapper]: http://datamapper.org/doku.php +[MySQL]: http://en.wikipedia.org/wiki/MySQL +[PostgreSQL]: http://en.wikipedia.org/wiki/PostgreSQL +[SQLite]: http://www.sqlite.org/ +[propiedades]: http://datamapper.org/doku.php?id=docs:properties +[validaciones]: http://datamapper.org/doku.php?id=docs:validations [orientado a aspecto]: http://en.wikipedia.org/wiki/Aspect_oriented -[asociaciones]: http://datamapper.org/doku.php?id=docs:associations -[DataMapper]: http://datamapper.org/doku.php -[hooks]: http://datamapper.org/doku.php?id=docs:hooks -[MySQL]: http://en.wikipedia.org/wiki/MySQL -[ORM]: http://en.wikipedia.org/wiki/Object-relational_mapping -[PostgreSQL]: http://en.wikipedia.org/wiki/PostgreSQL -[propiedades]: http://datamapper.org/doku.php?id=docs:properties -[SQLite]: http://www.sqlite.org/ -[validaciones]: http://datamapper.org/doku.php?id=docs:validations +[asociaciones]: http://datamapper.org/doku.php?id=docs:associations +[enganches]: http://datamapper.org/doku.php?id=docs:hooks diff --git a/book-content/es/2-getting-started/8-request-path.markdown b/book-content/es/2-getting-started/8-request-path.markdown index 01d5c182..5cb2d831 100644 --- a/book-content/es/2-getting-started/8-request-path.markdown +++ b/book-content/es/2-getting-started/8-request-path.markdown @@ -1,134 +1,123 @@ -# Camino de una petición +# Camino de una Petición * Esto será una tabla de contenidos (este texto será pegado). {:toc} -Todas las aplicaciones web actúan en respuesta a una petición HTTP por un -cliente. -Cada acción termina con una respuesta desde el servidor HTTP. -En este capítulo, seguiremos el flujo del programa -desde la petición del cliente hasta la respuesta. +Todas las aplicaciones web actúan en respuesta a una petición HTTP realizada por un cliente. +Cada acción termina con una respuesta proporcionada por el servidor HTTP. +En este capítulo, se presentara el flujo de programa a seguir +desde la petición del cliente hasta la respuesta otorgada por el servidor. -## Desde el Cliente hasta nuestra Puerta +## Del cliente a nuestra puerta -Los funcionamientos internos de la Internet están más alla el alcance of este -libro. -Sin embargo es útil recordar -que existe un cliente (eg, un navegador web) ahí afuera -y que la petición que genera pasa a travez de un número -de entidades (eg, proxies, caches, firewalls) para alcanzar nuestros servidores. +La manera de como funciona internamente la Internet están fuera del alcance de este libro. +Pero, sin embargo, es sumamente útil recordar +que existe un cliente (por ejemplo, un navegador web) que será utilizado +para generar una petición que pasara a través de un número +de entidades (proxies, caches, firewalls, entre otras) para alcanzar un determinado servidor. Cualquiera de estas entidades puede examinar la petición, modificarla, -y posiblemente almacenar lo que devolvamos. -Si todo va bien, esto será transparente al usuario -y de ninguna importancia para el servidor. +y posiblemente almacenar el resultado que retorne este servidor. +En el mejor de los casos, estas acciones serán transparentes al usuario +y de ninguna importancia para el servidor en cuestión. -Existen situaciones sin embargo (particularmente con sitios dinámicos), -donde estas actividades necesitarán ser tomadas en cuenta. -Existen también maneras para sacar ventaja de la infraestructura de la Internet -para reducir la carga en el servidor. -Esto puede ahorranos tanto ancho de banda como costos en equipamiento. +Sin embargo, pueden existir determinadas situaciones (particularmente con sitios dinámicos), +donde estas acciones necesitarán de ser tomadas en cuenta. +También existen maneras para obtener ventaja de la infraestructura de la Internet +para reducir la carga a realizar en el servidor. +Esto puede producir ahorros tanto en el ancho de banda como en los costos en equipamiento. ## Proxy Inverso (opcional) -La primera parada para una petición en una aplicación -es usualmente un proxy inverso (reverse proxy) tales como [NginX][] o el -[mod\_proxy][] de [Apache][] +La primera parada a realizar por una petición en una aplicación en funcionamiento +es usualmente un proxy inverso tales como el [NginX][] o el [mod\_proxy][] de [Apache][]. Dependiendo de la configuración, estos proxies pueden servir archivos estáticos -(eg, imágenes, hojas de estilo CSS, código JavaScript, videos). -Muchas veces, incluso permitiremos al proxy servir páginas cacheadas -sin siquiera interactuar con nuestra aplicación. +(pro ejemplo imágenes, hojas de estilo CSS, código JavaScript o videos). +Frecuentemente, se le permite al proxy servir páginas cacheadas +sin siquiera interactuar con su aplicación web. [Phusion Passenger][] no es un proxy inverso, _per se_. -Sin embargo, en aras del nuestro argumento pretendamos que sí lo es. -(Especificamente, que recibirá la petición a travez de Apache -y que enviará una petición [Rack][] al servidor de la aplicación.) +Sin embargo, en aras del nuestro argumento, se pretenderá que sí lo es. +(Específicamente, este recibirá una petición a través del servidor [Apache][] +y consecuentemente enviará una petición [Rack][] al servidor de la aplicación.) ## Servidor Web -Si la petición no ha sido ya retornada por el reverse proxy, -o si no está siendo usado ninguno, +En el caso que la petición no haya sido retornada por el proxy inverso, +o si no hay ninguno en uso, la petición será reenviada a un **servidor web**. [Mongrel][], [Thin][], [Ebb][], y un número de programas menos conocidos -se encargan de este rol. - -Una vez la respuesta es recibida por el servidor web, -esta será parseada y enviada al [Rack][] a travez de un manipulador (handler). +se encargan de cumplir con este rol. +Una vez que la respuesta sea recibida por el servidor web, +esta será parseada y enviada al [Rack][] a través de un manipulador. ## Rack y Merb -Merb recibe la petición como un entorno [Rack][]. -Un entorno Rack envuelve todo las cabeceras de estilo CGI para la petición. -Debido a que Merb usa Rack como una capa de abstracción, -cambiar servidores web es realmente fácil. -Puede que oigas a gente referirse a estos servidores web como adaptadores. - -Antes de que Merb despache la petición a travez de la stack, -uno puede adicionar "middlewares Rack". -Los middlewares Rack pueden procesar la petición antes de que sea enviada a -travez Merb. -Alternativamente, estos pueden "envolver" la petición, -permitiendo que código arbitrario sea ejecutado lo mismo antes que después de -que la petición viaje a travez de la stack. -Los middlewares Rack pueden ser herramientas muy poderosas, permitiéndote -mantener logs a la medida, cacheo, hacer análisis de rendimiento, etc. - -Nosotros no cubriremos extensivamente el uso de Rack aquí, -pero puedes encontrar la configuración Rack de Merb en el archivo -``config/rack.rb`` (en la aplicación de stack completa). - -## Enrutador (Router) - -Una vez la petición ha sido pasada a la stack, -esta le pregunta al enrutador adonde ir. -La petición entonces se envía sí misma al controlador. - -El trabajo del Enrutador es asignar parámetros extraidos de la petición -y decirle a la petición adonde ir. -En la mayoría de los casos, el enrutador mapea una petición a un método -(acción) de un controlador -y también asigna parámetros extraidos de la petición. - -Entre bastidores la framework Merb ha hecho ya cierto trabajo para tí. -En el momento que una petición alcanza el controlador, Merb se ha encargado de: - -* Extraer la ruta URI de la petición. -* Parsear cualesquiera datos Post o Query enviados por el cliente, - metiendolos en el hash ``params``. +Merb recibe una petición dentro del entorno [Rack][]. +Un entorno Rack envuelve todas las cabeceras de estilo CGI para una petición. +Debido a que Merb utiliza [Rack][] como una capa de abstracción, +el cambio de servidores web resulta ser sumamente simple. +Estos servidores web pueden ser también llamados "adaptadores". + +Antes de que Merb despache una petición a través de la stack, +uno puede adicionar diferentes "middlewares" en el [Rack][]. +Estos pueden procesar la petición antes de que esta sea enviada a través de Merb. +Alternativamente, también pueden "envolver" una petición, +permitiendo así la ejecución de código arbitrario tanto antes como después +del paso de la petición a través de la stack. +Los [middlewares][] del Rack pueden ser herramientas muy poderosas, permitiéndole +mantener registros de eventos a medida, cacheo, realizar análisis de rendimiento, etc. + +El uso de [Rack][] no será cubierto extensivamente en este capitulo, +pero usted puede encontrar la configuración del [Rack][] de Merb en el +archivo ``config/rack.rb`` (en la aplicación de stack). + +## Enrutador + +Una vez que la petición ha pasado al stack, +esta le pregunta al enrutador hacia donde debe dirigirse. +Entonces la petición se envía a sí misma hacia el controlador. + +El trabajo del Enrutador es la asignación de parámetros extraídos +de la petición aunque, ademas, debe direccionar a la misma. +En la mayoría de los casos, el enrutador conecta una petición a un +determinado método (acción) definido en un controlador +asignando aquellos parámetros extraídos de la petición al mismo. + +Detrás de escena, la plataforma Merb ya ha realizado cierto trabajo por usted. +Al momento que una petición alcanza un controlador, Merb se ha encargado de: + +* Extraer la ruta [URI][] de la petición. +* Parsear los datos Post o Query enviados por el cliente, + organizándolos en la colección ``params``. * Configurar el acceso a las cookies de la petición y a la sesión actual. -El desarrollador puede usar cualquiera de esta información para enrutar la -petición. -Por favor mira el capítulo sobre enrutamiento (???) para más información. +El desarrollador puede usar esta información para enrutar la petición. +Por favor, referirse al capítulo sobre enrutamiento (???) para más información. ## Acción del Controlador -La petición ha sido despachada a un método de un controlador. -Por ejemplo: el/la método/acción ``show`` del controlador ``Articulos``. -La acción puede mostrar una vista o simplemente retornar una cadena. -El valor retornado desde el método será usado para construir una respuesta Rack. -Una respuesta Rack es simplemente una tupla sencilla que contiene - ``[estado, cabeceras, cuerpo]``. +La petición es ahora despachada a un determinado método de un controlador. +Por ejemplo: el método o la acción ``mostrar`` del controlador ``Articulos``. +La acción puede mostrar una vista o simplemente retornar una cadena de caracteres. +El valor retornado por el método será usado para generar la respuesta del Rack. +Esta es simplemente una tupla sencilla que contiene [estado, cabeceras, cuerpo]. ## Hacia afuera -Finalmente Merb envía una respuesta Rack bien construida de regreso al servidor -web. -El servidor web a su vez conforma una respuesta HTTP que es enviada por el -cable. -El cliente recibe la respuesta y la interpreta para, por ejemplo, -mostrar una página web. - +Finalmente, Merb retorna la respuesta Rack bien construida al servidor web. +El servidor web, a su vez, confecciona una respuesta HTTP +que será enviada por el cable. +El cliente recibe la respuesta y la interpreta, por ejemplo, +mostrándola como una página web. ## Cacheo -Si el cacheo está habilitado, -la petición podría no viajar a travez de todo el proceso anteriormente descrito. -El Cacheo puede ocurrir dentro Merb, en un Middleware Rack, un servidor Proxy, +En el caso el cual el cacheo está habilitado, +la petición podría no viajar a través de todo el proceso anteriormente descrito. +El Cacheo puede ocurrir dentro Merb, en un middleware del Rack, un servidor Proxy, o el navegador web cliente. - - [Apache]: http://httpd.apache.org/ [GlassFesh]: /deployment/jrupor [mod\_proxy]: http://httpd.apache.org/docs/2.0/mod/mod_proxy.html @@ -138,3 +127,5 @@ o el navegador web cliente. [Phusion Passenger]: /deployment/passenger [Rack]: http://rack.rubyforge.org/ [Thin]: http://code.macournoyer.com/thin/ +[middlewares]: ... +[URI]: ... diff --git a/book-content/es/2-getting-started/9-router.markdown b/book-content/es/2-getting-started/9-router.markdown index 7ec787f1..73b516f6 100644 --- a/book-content/es/2-getting-started/9-router.markdown +++ b/book-content/es/2-getting-started/9-router.markdown @@ -1 +1,4 @@ -#Router \ No newline at end of file +# Enrutador + +* Esto será una tabla de contenidos (este texto será pegado). +{:toc} \ No newline at end of file diff --git a/book-content/es/2-getting-started/toc.markdown b/book-content/es/2-getting-started/toc.markdown index 0b5a90b5..821669c8 100644 --- a/book-content/es/2-getting-started/toc.markdown +++ b/book-content/es/2-getting-started/toc.markdown @@ -1,19 +1,78 @@ # getting-started - - - - - - - - - - - - - - - - - \ No newline at end of file + \ No newline at end of file