section 2-getting started completed

contribuitors updated

book-content/es/0-front-matter/2-contributors.markdown

@@ -1,6 +1,7 @@
 # Colaboradores
 
-Sin la ayuda de los siguientes colaboradores este libro no hubiese sido posible. Gracias a todos!
+Sin la ayuda de los siguientes colaboradores este libro no hubiese sido posible.
+Gracias a todos!
 
 **En order alfabético:**
 

book-content/es/2-getting-started/4-mvc.markdown

@@ -1,13 +1,70 @@
 #MVC
 
-MVC is an acronym that stand for Model, View, Controller.  It describe a form of web-application structuring that is easy to test and maintain because it separates business logic, server logic and content generation.  This is the structure of the standard Merb app the is generated for by the 'merb-gen app' command.  It is also the structure used by Rails, CakePHP, Django and many other popular web design tools.
+* Esto será una tabla de contenidos (este texto será pegado).
+{:toc}
 
-To develop in Merb effectively, it is important that one understand both how the structure works, and what the most effective way to work with it is.  This Chapter will discuss the overall framework; the following three chapter will look at each piece in detail.
+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.
 
-Models are the core of the framework.  They are responsible for the business logic of your application, and in Merb they are most often associated with database access through an ORM such as DataMapper or Active Record.  In some applications they are nothing more then a wrapper for a database table, but good developers will try to place as much in their model classes as possible describing relationships among various concepts and adding methods for any non-trivial piece of data retrieval or manipulation.
+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.
 
-Views are the glitzy outer shell of an application.  Views are responsible for generating the actual content returned by a request.  Most commonly Views are written in a templating format like eRB or Haml.  Wise developers will attempt to put as little code as possible into a View.
+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
+a través de un ORM tal como DataMapper o Active Record.
+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
+tales como relaciones de datos y métodos
+para cada manipulación y recuperación no trivial de datos.
 
-Controllers deal with taking an incoming request and turning it into a response.  They are responsible for interpreting the incoming request, getting instances of the needed Models, and passing this information along to the View.  Novice users are often tempted to add lots of code into the controller layer, but this leads to brittle and hard to test code.  Instead, developers are well advised to keep their controllers as 'skinny' as possible by pushing and code that does not directly relate to the request/response cycle or the gathering of data into the Model.
+Las [Vistas][] son el ostentoso cascarón exterior de una aplicación.
+Las Vistas son 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
+tales como [Erb][] (Ruby embebido) o [Haml][].
+Los desarrolladores sabios intentarán poner tan poco código como sea posible en
+sus Vistas.
 
-In the default Merb application, the code for all three of these pieces is found in folders under the 'app' directory.  In the next chapters we will look at how Merb implements each of these parts.
+Los [Controladores][] se encargan de recibir una petición entrante
+y 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.
+
+En una aplicación Merb típica,
+el código para cada una de estas 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.
+
+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.
+
+
+<!-- Links -->
+[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

book-content/es/2-getting-started/5-controllers.markdown

@@ -1 +1,242 @@
-#Controllers
+# Controladores
+
+* Esto será una tabla de contenidos (este texto será pegado).
+{: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.<!-- break -->
+> Provée medios para ofrecer salida al usuario presentándole menús u otros
+> medios de entrar comandos y datos.<!-- break -->
+> 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.<!-- break -->
+> - [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.
+
+Concretamente el controlador es responsable del mapeo de una acción del
+usuario-final con una respuesta de 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``.
+
+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.
+
+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.
+
+## Generando controladores
+
+Tú puedes  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
+{:lang=shell html_use_syntax=true}
+
+El comando anterior genera varios archivos.
+El archivo controlador (``birds.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).
+
+Echemos un vistazo rápido al controlador generado:
+
+    class Birds < Application
+
+      def index
+        render
+      end
+
+    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``.
+En el contexto de un controlador,
+a menudo nos referimos a estos métodos como **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.<!-- break -->
+(_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
+  {: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
+{: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.
+
+Veamos el archivo generado:
+
+    class Cats < Application
+      # provides :xml, :yaml, :js
+
+      def index
+        @cats = Cat.all
+        display @cats
+      end
+
+      def show(id)
+        @cat = Cat.get(id)
+        raise NotFound unless @cat
+        display @cat
+      end
+
+      def new
+        only_provides :html
+        @cat = Cat.new
+        display @cat
+      end
+
+      def edit(id)
+        only_provides :html
+        @cat = Cat.get(id)
+        raise NotFound unless @cat
+        display @cat
+      end
+
+      def create(cat)
+        @cat = Cat.new(cat)
+        if @cat.save
+          redirect resource(@cat), :message => {:notice => "Cat fue creado satisfactoriamente"}
+        else
+          message[:error] = "Cat 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)
+        else
+          display @cat, :edit
+        end
+      end
+
+      def destroy(id)
+        @cat = Cat.get(id)
+        raise NotFound unless @cat
+        if @cat.destroy
+          redirect resource(:cats)
+        else
+          raise InternalServerError
+        end
+      end
+
+    end # Cats
+{: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.
+
+Pero antes de que revisemos el código, hablemos 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
+[recursos][] son definidos y accedidos.
+De esta manera son los [recursos][] los componentes claves de REST.
+
+**¿Qué es un recurso, en el 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.
+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.
+
+**Aquí está cómo es que la gente usualmente mapea recursos web REST:**
+
+**URI:**      http://site.com/cats o http://site.com/cats/1-felix
+(identificador/dirección global)<!-- break -->
+
+**Formato:**  Tipo o extensión MIME (HTML, JSON, XML, YAML, CSV, PDF, ...)<!-- break -->
+
+**acción:**   mapea los métodos HTTP (POST, GET, PUT, y DELETE) a métodos de recursos
+
+Si un recurso es definido, Merb usa la ``URI`` y el método HTTP
+para seleccionar un controlador y una acción.
+
+
+<!-- Links -->
+[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]
+[Trygve Reenskaug]: http://en.wikipedia.org/wiki/Trygve_Reenskaug
+[View]:             /getting-started/view
+
+<!-- References -->
+[^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
+
+<!-- Abbreviations -->
+*[HTTP]:    Hypertext Transfer Protocolo
+*[REST]:    Representational state transfer