El segundo día mi serie de posts sobre mi aprendizaje de Rails empezó con el Capítulo 4 del libro “Agile Web Development With Ruby on Rails: Second Edition“. Para este capítulo el libro prometía crear una aplicación sencilla de demostración llamada simplemente “demo”. De manera más puntual, estas fueron mis impresiones…
- Creamos la aplicación a través de la línea de comando. Con simplemente escribir “
rails nombre_aplicación” en la raíz del servidor, bastó para que Rails automágicamente generara el esqueleto de la aplicación, incluyendo estructura y archivos de configuración básicos. Buen comienzo que ahorra bastante tiempo en 1) crear cada uno de estos archivos manualmete y 2) pensar en la estructura de tus aplicaciones si no te has definido estándares (y aún así uno siempre busca mejorarlos cada vez que se empieza un proyecto nuevo) - A través del comando “
ruby script/server” en la raíz de tu proyecto nuevo, inicias un servidor WEBrick, el cuál trae una cónsola que hace trazas completas a todo lo que se esté ejecutando en la aplicación, ¡perfecto para debuggear! No más problemas con SQL’s extraños. Siempre quise algo así con PHP… - Creamos nuestro primer controlador con el comando “
ruby script/generate controller Nombre_Controlador“. Esto genera la estructura de carpetas y archivos necesarias para el funcionamiento del controlador. Lo interesante aquí es que Rails tiene su propia estandarización de nombre para todo, por ejemplo, si llamas a un controlador “Hola”, Rails automáticamente creará las clases HolaController que heredará las propiedades de la clase ApplicationController, las Vistas, los Helpers (métodos que ayudan a estandarizar funciones que generan HTML en las Vistas). Todo esto viene ya listo para simplemente crear nuestra lógica de negocios, sin preocuparnos por errores de nombramiento, herencias, enrutamientos, etc., en sus carpetas respectivas. Menos esfuerzo en determinar nombre y rutas de archivo = ahorro de tiempo = una maravilla. - Nos explican la manera de Rails de manejar los URL’s. Básicamente todo lo que venga luego de la raíz del servidor es un controlador, y lo que venga después del controlador es una acción, es decir: http://urlejemplo.com/controlador/accion. Ejemplo: http://tiendaejemplo.com/productos/mostrar. En este ejemplo el controlador sería Productos y Mostrar la acción (mostrar la lista de todos los productos). Un controlador puede tener muchas acciones, siguiendo este ejemplo, el controlador Productos puede tener las acciones Mostrar, Agregar (agrega al carrito de compras), Detalle (muestra el detalle de un producto en específico), etc. Esta es, a la final, la manera cómo el navegador (y el usuario final) hace peticiones al sistema: pide un controlador y una acción del mismo. Así que hay que empezar a pensar con esa mentalidad.
- Creamos un controlador de ejemplo llamado “Say” (decir) con su acción “Hello” (hola) y nos pide entonces crear la Vista correspondiente para esa acción, que en pocas palabras será el HTML que muestre en el navegador todo aquello que queramos desplegar. La ruta predefinida de esa vista está en /app/views/say/hello.rhtml (noten que el archivo se debe llamar igual que la acción del controlador). Estos HTML pueden ser dinámicos, y para ello existen 2 técnicas: “Builder Templates”, para la cuál no entramos en detalles aún, y ERb, que es simplemente embebir código Ruby en los .rhtml, como se pueda hacer con PHP y JSP tradicional, entre los tags < %= %>. Es importante destacar que las Vistas heredan perfectamente las propiedades de los Controladores, de manera que si yo creo una variable en un Controlador, la puedo acceder en las Vistas correspondientes. Esto nos permitirá la gran ventaja de separar la capa de lógica de la presentación, y es imperativo mantenerlo siempre en cuenta, ya que de esto se trata el MVC y nos dará mayor flexibilidad al hacer actualizaciones futuras de código, especialmente si trabajamos el proyecto en un equipo. Todo tiene su lugar, es fácil de entender, debuggear y no hay necesidad de repetir el mismo código en distintas partes de nuestra aplicación.
- Nos muestran la manera de hacer links entre páginas. Si bien podríamos hacer los links convencionales con la etiqueta HTML respectiva, Rails trae un helper llamado “link_to” que no rompería los links si por alguna razón decidimos cambiar la estructura de URL’s de un site (por ejemplo, meter toda la aplicación en una carpeta). Ejemplo de uso:
< %= link_to "Hola!", :action => “hello” %>, dónde “Hola!” es lo que se mostrará en el enlace y:action => "hello"es la acción que ejecutará del controlador.
Esto fué todo para el capítulo 4. Aprendimos de manera muy básica como hacer las cosas en Rails, como estructurar archivos, carpetas y trabajar con controladores y vistas. Éste quizá sea el cambio de paradigma más grande que pueda tener alguien que venga de PHP o Java tradicional, y les aseguro con toda firmeza que es para mejor. La facilidad de trabajar los proyectos de esta manera no tiene precio. Hasta ahora Rails sólo me ha dado entender que hubo mucho trabajo de ingenio y mucha experiencia detrás del framework, para llegar a este punto. Se siente bastante pulido.
No hay que olvidar la belleza de un lenguaje como Ruby. Ejemplos: < % 3.times do %> repite una acción 3 veces, < % 3.downto(1) %> cuenta en reversa de 3 a 1, < % Time.now %> de la hora actual, y mi favorito hasta ahora: < % 1.hour.from_now %> te da la hora dentro de una hora. Y esto imagino que sólo es la punta del iceberg. ¡No puedo esperar aprender más!
El siguiente capítulo va directo al grano y nos enseñará a hacer una aplicación de la vida real. Haremos un carrito de compras, por supuesto incluyendo base de datos.
Keep on railing!