Posts Tagged Ruby
Ruby on Rails – Layouts y Hojas de Estilo
Posted by Xavi in Programación Web on 12/09/2011
Casi todas las aplicaciones web tiene una característica en común (y nótese que he dicho CASI TODAS, no todas) y es que la mayoría de sus páginas responde a un mismo modelo. Esta similitud entre páginas de la misma aplicación no ha pasado por alto a los responsables de desarrollo de frameworks y, actualmente, buena parte de éstos ya incorporan diferentes herramientas que nos ayudan a lidiar con la repetición de código HTML que estas similitudes comportan.
El nombre escogido bajo el cual se gestionas la repetición de componentes y estructuras entre páginas de una misma aplicación es “layouts”
Layouts
Ruby on Rails (o RoR, un acrónimo que es posible que use de aquí en adelante) tiene un sistema de gestión de layouts muy sencillo que se aprende en un periquete. Evidentemente, detrás de este sistema básico se esconde la posibilidad de profundizar en la funcionalidad y realizar tantas piruetas como se quiera con la gestión de los layouts de nuestra aplicación.
Durante la generación de la aplicación, de hecho, ya tenemos una primera pista de por dónde van a ir los tiros pues dentro de la carpeta app/views podemos encontrar un subdirectorio llamado layouts.
Con un poco de experiencia en el desarrollo web (y más concretamente en Java 
) el primer impulso que uno podría tener sería el de pensar: “Oye, seguro que en el controlador puedo definir que layout quiero utilizar asignando el nombre del fichero a una variable o llamando a un método”. Sería lo normal… es a lo que nos han estado acostubrando desde pequeños… pues esta vez no nos hará falta; si no se quiere profundizar mucho en el tema, RoR nos permite utilizar un layout simplemente creando un fichero HTML con pedazos de Ruby embebido que se llame como el controlador que lo va a usar.
Por ejemplo, si tenemos un controlador llamado CondemorController (el archivo se llamará condemor_controller.rb) simplemente con tener un archivo, con las características que comentábamos en el párrafo anterior, llamado condemor.html.erb en la carpeta de layouts éste último será usado por el controlador para generar la página web de respuesta.
A todo esto, los primeros de la clase ya estarán pensado: “pues que co*azo de sistema, mi aplicación utiliza el mismo layout para todos los controladores”. Los que hayáis pensado esto, (podéis mandarme 50 euros y) os perdonaré, básicamente porqué yo mismo lo pensé cuando empezaba a trastear on RoR, pero esta gente se ha adelantado, se ha adelantado y permite que definamos un layout por defecto. En caso de no encontrar un archivo de layout que corresponda al controlador que está preparando la respuesta, se utiliza el layout por defecto de la aplicación para mostrar la respuesta al usuario.
Si lo pensamos bien, este método nos ofrece una gran variedad de combinaciones sin que esto conlleve un aumento en la complejidad de nuestra solución. Por un momento pensad la flexibilidad de este mecanismo para la creación de landing pages personalizadas o simplemente la creación de páginas especiales (como manuales o foros de ayuda) que no siempre necesitan ceñirse a la misma estructura que el resto de la aplicación. Es muy potente y muy simple, y la simplicidad a la hora de gestionar este tipo de estructuras nos puede ayudar mucho a aumentar nuestra productividad.
Hojas de estilos
Una herramienta básica en el uso de los layouts son las hojas de estilo. Las hojas de estilo (CSS) nos aportan una gran flexibilidad a la hora de definir el estilo gráfico de nuestras páginas web y bien aplicadas pueden hacer magia 
En RoR, las aplicaciones tienen un directorio llamado public dónde se deberían almacenar todos sus contenidos estáticos (CSSs, JSs, imágenes y otro tipo de contenido estático). En un primer momento podríamos pensar que, simplemente sabiendo como vamos a desplegar la aplicación, tendríamos suficiente en poner un path relativo en la etiqueta HTML para cargar los archivos CSS y listos; pero, imaginaros que el despliegue de la aplicación acaba siendo en un servidor con unos configuración un tanto peculiar, o que esperábamos que el domino apuntase a la carpeta public y de golpe apunta a la raíz de la aplicación (esto no debería pasar nunca… ehemmm). Para solucionar los problemas que podrían ocasionar situaciones como la anterior tenemos una función que nos permitirá cargar una hoja CSS sin tenernos que preocupar por la ubicación final de los ficheros de la aplicación. Esta función se llama stylesheet_link_tag y a continuación os escribo un pequeño ejemplo de como podría utiilzarse en un archivo de layout:
...
<head>
<title>Aplicación con estilo</title>
<%= stylesheet_link_tag “style”, :media => “screen” %>
</head>
<body>
...
NOTA: El archivo que se carga con esta función es style.css y se encuentra en la carpeta public de la aplicación.
En el ejemplo podemos ver como el uso de la función no representa un gran esfuerzo en comparación con los quebraderos de cabeza que puede ahorrarnos. Dadle una oportunidad.
Y con esto terminamos una entrega más de este pequeño paseo por Ruby on Rails!
Me estoy divirtiendo mucho con este mini-proyecto y espero estar en situación de anunciaros la disponibilidad del software dentro de poco; ahora mismo tengo que acabar de añadir las cabeceras de la licencia y avanzar un poco más en el desarrollo, bueno, bastante más para poder ofrecer algo funcional, para que engañarnos
Seguid atentos!
Ruby on Rails – Controladores y Vistas
Posted by Xavi in Programación Web on 07/09/2011
Ruby on Rails es un framework para el desarrollo web que implementa el patrón Modelo-Vista-Controlador orientado a la web (en según que documentación también puede ser que lo encontréis como patrón MVC tipo 2). Esto quiere decir que hay una separación efectiva entre el componente que recibe y gestiona las peticiones realizadas desde el navegador (controlador), el componente que se encarga de construir la interfaz que se presentara al usuario (vista) y la capa que gestiona el comportamiento del núcleo de la aplicación (modelo).
A continuación vamos a explicar los controladores y como generarlos automáticamente…
Controladores
Tal y como comentábamos, los controladores son los encargados de recibir las peticiones de los usuarios y disparar las acciones para poder devolver la respuesta a los usuarios. Estos controladores se implementan mediante clases en la carpeta app/controllers y necesitan implementar unos métodos que se encargarán de ejecutar lo que llamaremos “acciones”.
Para saber que controlador y que método del controlador tiene que llamar, Rails (por defecto) divide las URL de la manera que vamos a explicar a continuación:
Dada la URL: http://servidor/controlador/acción
Si Rails se está ejecutando en el servidor “servidor”, éste llamará al método “acción“ de la clase ControladorController (en el archivo controlador_controller.rb).
Del párrafo anterior podemos deducir que la creación de controladores implica la creación de archivos con nombres concretos. Para evitar problemas con los nombres de los archivos y facilitar la vida a los desarrolladores, la generación de estos componentes está automatizada en el framework que estamos estudiando. Como aun no tenemos ni un sólo controlador (si arráncaramos el servidor web ahora mismo sólo veríamos la página por defecto que incluye Rails en su servidor web) vamos a crear uno desde cero.
Para generar el controlador nos situamos en la raíz del proyecto y ejecutamos el siguiente comando:
script/generate controller index index
La nomenclatura de los controladores y las acciones es libre, pero en este ejemplo vamos a utilizar el controlador IndexController y la acción index para definir la acción que responderá a las peticiones que se realicen a la raíz de nuestra aplicación (veremos como definir que controlador y que acción llamar en las peticiones a la raíz de la aplicación al final de este artículo). La razón por la cual utilizo estos nombres es porqué son los que se utilizan por defecto en el Zend Framework y la implementación del patrón MVC del ZF y Rails son, bajo mi punto de vista, muy parecidas.
La salida de la consola cuando ejecutemos la operación anterior debería ser la siguiente:
En la captura de pantalla anterior podemos observar como a parte del fichero index_controller.rb también se han creado ficheros para tests, helpers y vistas.
Pero, qué son las vistas? les hechamos un vistazo en un momento. Dejadme que muestre el contenido de nuestro controlador y vamos en seguida
El contenido del fichero del controlador es el siguiente:
class IndexController < ApplicationController
def index
end
end
El código, evidentemente está vacio (el dia que salga un framework que escriba el código de lo que el desarrollador está pensado habremos llegado DEMASIADO lejos 
) pero podemos ver como IndexController hereda de una clase llamada ApplicationController (propia de Rails) y que el método index ya está también definido.
Ahora que nos hemos cercionado de que nuestro controlador no está haciendo nada, vamos a mirar que secretos nos esconden las vistas…
Vistas
Las vistas, básicamente son ficheros *.erb (Embedded Ruby) que contienen su parte estática en HTML y su parte dinámica en código Ruby. Como bien os podéis imaginar, el resultado de la ejecución de sus partes dinámicas determina la página web que se mostrará al usuario en respuesta a su petición. Para personalizar el pequeño test que estamos realizando vamos a modificar el contenido que el generador automático haya guardado en el fichero index.html.erb por el siguiente contenido:
<h1>Index Controller</h1>
<p>Hello World! That's just an static view</p>
Para ver los efectos de este cambio podemos situarnos otra vez en la raíz de nuestro proyecto y ejecutar el comando para ejecutar el servidor de desarrollo que Rails nos proporciona por defecto.
script/server start
Una vez arrancado el servidor, al visitar la página http://localhost:3000/index/index deberíais poder ver una imagen parecida a la siguiente:
One more thing…
Como en el anterior artículo nos quedamos un poco cortos vamos a tirar un poquito más del carro y vamos a ver muy poquito de lo que Rails ofrece de forma automática. Para ello vamos a tener que definir una variable de clase en el controlador, por ejemplo, en el método index (el único que tenemos hasta ahora) y lo vamos a dejar de la siguiente manera:
def index
@variable = "dynamic";
end
Y el contenido de la vista lo vamos modificar para que quede así:
<h1>Index Controller</h1>
<p>Hello World! That's just a <%=@variable%> view</p>
Si no hemos parado el servidor, simplemente recargando la página que hemos consultado antes vamos a ver el resultado de los cambios:
El hecho de que la vista pueda acceder a las variables de las instancias de los controladores es algo que Rails nos provee de forma completamente transparente para los desarrolladores. Este ejemplo puede saber a poco a muchos de los que estéis acostumbrados a la programación y es que, realmente, esto es sólo una minúscula parte de la punta del iceberg de todas las cosas que Rails ha ido automatizando en el proceso de desarrollo de una aplicación web.
A parte de esta simple modificación para hacer la vista un poco más dinámica también os avanzo como hacer que el controlador “index” y su acción “index” se utilicen para responder las peticiones que se hacen a la raíz del sistema. Esto, implica un cambio en la configuración del comportamiento de la aplicación en si misma y, por lo tanto, vamos a tener que editar el fichero config/routes.rb.
El cambio necesario para que la aplicación se comporte como decíamos implica encontrar la línea de código que pone:
# map.root :controller => "welcome"
Y sustituirla por la siguiente:
map.root :controller => "index", :action => “index”
Sin reiniciar el servidor, visitando http://localhost:3000/ veremos que el resultado de la acción “index” de nuestro IndexController ya se muestra cuando visitamos la raíz del servidor.
Bueno, esto ha sido todo por hoy, en el horizonte tenemos templates, scaffolds y mucho más, no faltéis!
Primeros pasos con Ruby y Rails
Posted by Xavi in Programación Web on 03/09/2011
Hace años la programación web tenía mucho más que ver con la artesanía que con la programación. Cualquier pequeño desarrollo requería un número de lineas de código que nunca nadie más volvería a utilizar (y seguramente comprender). Pues bien, para facilitar la vida a los desarrolladores, empezaron a llegar lenguajes de programación más ágiles para el desarrollo web como PHP y, posteriormente, frameworks que nos facilitaban aun más la vida al traer un gran número de funcionalidades ya implementadas (como en el caso de Zend Framework para PHP o GWT para Java).
De entre todos estas tecnologías de (relativa) reciente aparición, un minoritario lenguaje de programación, Ruby, se encontró por sorpresa con un ligero pero eficiente framework para el desarrollo web (cosas que pasan en la vida ), Rails. Y de este binomio surgió una herramienta que considero que pude ser clave en los próximos años.
Por el interés que me ha suscitado tanto Ruby como Rails, intentaré presentar las operaciones más básicas de este framework junto con el lenguaje de programación que lo hace posible -en un número aun indeterinado de artículos-. El resultado de éstos estarà disponible como software libre en un repositorio público que aun está por decidir (pero que muy probablemente será GitHub).
Empezamos?
Antes de empezar a explicar como meternos en Ruby y Rails podría soltar un rollo teórico de unos cuantos párrafos (que si Ruby es un lenguaje completamente orientado a objeto, que si Rails es un framework que implementa el patrón MVC, que si no hace falta relanzar el servidor para probar cambios, etc, etc.) pero prefiero ir comentando este tipo de cosas a medida que vayamos avanzando. Desde mi punto de vista es un poco más ameno y da menos miedo.
Instalando Ruby y Rails
Para empezar a desarrollar en Rails es necesario tener instaladas las librerías de Ruby. Para eso deberemos instalar los siguientes paquetes en Linux:
- ruby (o ruby1.8): Paquete básico que contiene el core de Ruby.
- rubygems: Nos permitirá utilizar el comando gems más adelante, básico para desarrollar en Rails.
- libopenssl-ruby: Dependencias necesarias para el uso de según que algoritmos de encriptación.
- ruby1.8-dev: Cabeceras de Ruby.
- libsqlite3-dev: Sistema ligero y flexible de bases de datos que nos ayudará en el desarrollo en local de nuestra aplicación en Rails. Realmente este paquete no sería necesario pero lo vamos a utilizar.
NOTA: Antes de empezar a discutir sobre versiones voy a dar una explicación sobre el uso de la versiones en este proyecto. He decidido utilizar la rama de Ruby 1.8 y Rails 2.2 porqué son las versiones estables en el momento en que empecé con esto. En cuanto esté un poco más familiarizado ya me animaré a escribir sobre las mejoras que Rails 3.1 o Ruby 1.9 nos pueden aportar.
Para instalar estos paquetes en Ubuntu podemos utilizar apt-get o aptitude indistintamente pero tened en cuenta que para otras distribuciones de Linux el nombre de estos paquetes puede variar sustancialmente. Una vez hayamos instalado estos paquetes vamos a utilizar el comando gems -igual en todas las plataformas-.
Con las dependencias instaladas, vamos a proceder a instalar Rails utilizando el propio gestor de paquetes de Ruby: Gems. Este gestor nos permite instalar diferentes librerías y frameworks de Ruby en nuestro equipo sin tener que sufrir por las diferencias entre plataformas. Así, utilizando este gestor podemos ejecutar el siguiente comando directamente en la consola para instalar Rails:
sudo gem install rails --version 2.2.3
Si hemos tenido éxito con todas estas operaciones ya nos podemos empezar a crear nuestra aplicación.
Crear un nuevo proyecto
El fucionamiento de Rails en cuanto a la creación del proyecto y sus diferentes componentes es bastante parecido al de las herramientas por línea de comando de Zend Framework (os había comentado ya que soy bastante fan del ZF?). De este modo, para crear una nueva aplicación en Rails sólo tenemos situarnos en el directorio dónde vayamos a guardar este proyecto y ejecutar el siguiente comando:
rails webapp
Esto nos generará un arbol completo de nuestra nueva aplicación. Explorad su contenido minuciosamente y cuando no entedáis nada volved para el siguiente artículo
Bueno… como creo que os dejo con demasiado por hacer os pongo un pequeño resumen de lo que podéis encontrar en el árbol de directorios del proyecto, que no soy tan malo!
Primero los directorios:
- app: Básicamente es el directorio dónde vamos a desarrollar la aplicación, dentro de esta carpeta podemos encontrar las clases correspondientes a modelos, controladores, scripts relacionados con las vistas y todo tipo de archivos relacionados con la aplicación a desarrollar.
- config: En este directorio se encuentran los archivos dónde vamos a definir a que base de datos nos conectamos, en que entorno nos encontramos (sí, Rails nos permite definir diferentes entornos como “ddevelopment”, “testing” y “production” para facilitarnos la vida) o que routing van a seguir las peticiones HTTP que reciba la aplicación.
- db: En este directorio vamos a ver el schema de la base de datos que definamos a medida que desarrollemos la aplicación y otros archivos que nos ayudarán con el mantenimiento de la misma (si tienes curiosidad sobre esto último busca información sobre “migrations” en la documentación de Rails).
- doc: Directorio dónde vamos a generar la documentación de nuestra aplicaciónm (esa documentación que todos los desarrolladores amamos generar!).
- lib: Módulos y librerías externas que podamos necesitar al largo del desarrollo.
- log: Pues eso, el directorio dónde seguramente van a ir a parar los logs de nuestra apliación (por lo menos en desarrollo).
- public: Si has trabajado alguna vez con ZF, este directorio actual exactamente igual en Rails que en el framework de PHP. Básicamente se encarga de almacenar los recursos que tienen que ser accesibles por el servidor web (css, imágenes, js adicionales…).
- script: Contiene los scripts que se encargan de arrancar el servidor de pruebas y puede almacenar otros scripts útiles para la gestión de la aplicación (despliegue u otras operaciones importantes).
- test: Todos los tests de la aplicación (unitarios y de otros tipos que ya veremos) van a ir almacenados en esta carpeta.
- tmp: Archivos temporales. Si tu aplicación genera “basurilla” no persistente puedes almacenarla ahí.
- vendor: Directorio para el almacenamiento del código de Ruby, Rails y gemas que utilices en tu proyecto.
Y los dos archivos generados:
- Rakefile: Equivalente del Makefile pero para Ruby.
- README: Un fichero de readme es un fichero de readme, no le daremos más vueltas pero la lectura de su contenido inicial está muy recomendada.
Hoy pretendía empezar a tocar algo de código pero el post estaba empezando a crecer mucho así que espero veros por aquí en unos días.
Cheers and Rubies!!
¿Me sigues? :-)
Comentarios recientes