Published 17 years ago
(updated 13 years ago)
Parte 4. El Framework Rails
El presente artículo es el cuarto y último de la serie que tiene la intensión de introducir al lector los principales elementos del lenguaje de programación Ruby y del framework Ruby on Rails. En esta ocasión se tratarán los temas del controlador y las vistas.
El Controlador
Contrario a lo que podría indicar el nombre del patrón: MVC, en Rails se aconseja desarrollar primero el controlador antes que la vista. Para lograr esto, Rails echa mano de una clase especial llamada ApplicationController, a través de los siguientes pasos:
a) generar una clase derivada de ApplicationController y
b) manipular con esta clase, a nuestra clase que representa el modelo para lograr el acceso a la base de datos.
Manteniendo la misma filosofía de generación automática de capas, el comado generate permite uitlizar el parametro controller para acceder a la clase ApplicationController, para invocarlo abriremos una sesión en linea de comandos, nos posicionaremos en el directorio railsass e
introduciremos:
path/trabajo/railsass>ruby script/generate controller Usuario
Además de haber creado automáticamente el archivo con el nombre
usuario_controller.rb destinado a contener la clase controladora, también se habrá creado un directorio usuario debajo del directorio views que contendrá los archivos RHTML que manejarán las vistas, un archivo usuario_controller_test.rb para realizar pruebas funcionales y archivo usuario_helper.rb dentro del directorio helper que podrá utilizarse para albergar clases adicionales de soporte que puedan requerirse.
Al abrir el archivo usuario_controller.rb que se encuentra dentro del
directorio app/controllers ,podemos observar que en este se encuentra la clase UsuarioController la cual es derivada de ApplicationController:
class UsuarioController < ApplicationController
end
Ahora bien, los constructores de Rails han diseñado el framework de tal manera que los métodos que se definan dentro de esta clase coincidan con las acciones que se generen en las vistas, es decir, si se desea que se realice un evento específico dentro de las vistas, el código que representa ese evento podrá estar contenido dentro del nombre del método o función que definamos dentro del controlador.
Por ejemplo, supongamos que dentro la vista new.rhtml invocamos al evento agregrar un nuevo Usuario esto, mediante la liga
<%= link_to “Agregar un nuevo Usuario”, {:action => ‘new’}%>
Entonces si deseáramos que al activar esta liga se ejecute un código determinado X, tendremos que definirlo dentro un método o función del controlador cuyo nombre coincida con el nombre de la acción, en este caso new.
El siguiente diagrama intenta ilustrar mejor este mecanismo.
Una vez entendido este concepto podemos proceder a incorporar la parte que manejará al modelo actualizando al controlador:
class UsuarioController < ApplicationController
#---Mostrar la lista de Todos los Usuarios---#
def list
@usuarios = Usuario.find( :all )
end
#--- Crear un nuevo Usuario en Memoria ---#
def new
@usuario = Usuario.new
end
#---Creamos Un Nuevo Usuario ---#
def create
@usuario = Usuario.new( params[:usuario] )
if @usuario.save
redirect_to :action => ‘list’
else
render :action => ‘new’
end
end
#---Mostrar el detalle de Un Usuario---#
def show
@usuarios = Usuario.find( params[:id] )
end
end
Como se puede apreciar a excepción del método show que muestra la lista de todos los Usuarios, hemos creado varios métodos que corresponderían a la funciones CRUD de un objeto de negocio Usuario.
Por otra parte es interesante observar como es que a su vez estos métodos manipulan al Usuario, es decir, dentro de ellos se invocan las diferentes funciones de ActiveRecord, de ahí que el método find de Usuario acepte como parámetro un objeto específico, como una variable de entorno (params[:id) o un símbolo (:all) que representa la condición para regresar todos los objetos Usuario.
Por otra parte, la invocación de método redirect_to resulta en la una nueva llamada a la acción y el refrescado de la página web correpondiente.
Para simplificar nuestra revisión en este momento nos concentraremos solo en un objeto, no tocaremos las relaciones (behaviours)
entre otros tipos de objetos de negocio.
La siguiente étapa es la construcción de las vistas.
La(s) Vista(s)
Como se explicó en la sección anterior, el controlador atiende peticiones de las vistas a través de sus métodos. El nombre de estos métodos coinciden con las acciones a invocarse en las vistas.
Ahora bien, de la misma manera que acontece en otras partes del framework, la convención que los diseñadores de Rails han empleado para definir las vistas, es hacer coincidir el nombre de los archivos que contengan a las vistas, con el nombre de los métodos que representarán a las acciones a invocarse dentro de los controladores.
Por ejemplo, en nuestro caso UsuarioController tiene los métodos list, new y show, por ende generaremos los archivos list.rhtml, new.rhtml,
show.rhtml que serán los que invocaran a estos métodos y se definen
dentro del directorio app/views/usuario, sin embargo a diferencia de lo que sucede con el controlador y el modelo, el comando generate no tiene un parámetro específico para generar los archivos .rhtml que contendrán a las vistas, por esta razón es necesario crearlos a mano.
El siguiente diagrama trata de ilustrar este mecanismo
Un comentario al margen es que existe un mecanismo llamado
scaffolding que permite la generación automática de todas las vistas y un formato homogéneo de las mismas. Sin embargo en esta ocasión no explicaremos este mecanismo con el fin de que el lector conozca y maneje los elementos básicos para manipular vistas.
A continuación se muestra un ejemplo del código de las vistas, en este caso sería de la vista list.rhtml.
<html>
<head>
<h3>
Historia 15 - USUARIOS - Nuevo
</h3>
</head>
<body>
<h1>Agregar un Nuevo Usuario</h1>
<%= start_form_tag :action => ‘create’ %>
<p><label for=”usuario_nombre”>Nombre</label><br/>
<%= text_field ‘usuario’, ‘nombre’ %></p>
<p><label for=”usuario_apellido”>Apellido</label><br/>
<%= text_field ‘usuario’, ‘apellido’ %></p>
<p><label for=”usuario_tipo”>Tipo</label><br/>
<%= text_field ‘usuario’, ‘tipo’ %></p>
<p><label for=”usuario_permisos”>Permisos</label><br/>
<%= text_field ‘usuario’, ‘permisos’ %></p>
<%= submit_tag “Create” %>
<%= end_form_tag %>
<%= link_to ‘Back’, {:action => ‘list’} %>
</html>
Formatos de los archivos de vistas
Al analizar el código RHTML observamos que en estos estan presentes instrucciones HTML y lo que aparenta ser codigo Ruby; en efecto lo es.
Recordemos la arquitectura de Rails: La parte de las vistas esta contenida en archivos .rhtml que son interpetados por el programa ERb, el cual a su vez intepreta, ejecuta y substituye las instrucciones de Ruby y convierte su salida en HTML la cual es entregada al webserver
que finalmente devuelve al browser para su interpretación.
Observemos también que en la vistas, se puede llamar directamente a los objetos de negocio que representan el modelo, esto, sin necesidad de incluir ninguna librería, mas importante aún es recordar que el controlador el responsable de crear este tipo de objetos. Para nuestro caso: @usuario.
Otro punto interesante es el código inmerso dentro de las etiquetas <%= start_form_tag %> … <%= end_form_tag%>, este es una instrucción preconstruida en Ruby que es interpretada por ERb la cual permite el desarrollo de formas complejas en HTML de una forma rápida y sencilla.
Finalmente reinicializaremos nuestro webserver WEBRick (si es que este se encuentra apagado).
ruby script/server webrick
Y arrancaremos el web browser de nuestra preferencia apuntándolo a la siguiente dirección:
http://localhost:3000/usuario/list
La 1ra. vez deberá aparecer una página parecida a la siguiente:
Al darle click a la liga “Agregar Nuevo Usuario” se desplegará en pantalla una forma. Introduzcamos un par de usuarios de ejemplo:
Nombre: Liliana
Apellido: Allen
Tipo: 1
Permisos: rwx rwx rwx
Nombre: Sebastian
Apellido: Coe
Tipo: 2
Permisos: rrr rxx rwx
Y demos click en el boton “Create” al final de la introducción de los datos de cada usuario
Podemos percatarnos que una vez que finalizamos la introducción de cada usuario mediante el botón “Create” la aplicación nos regresa a la página donde se enlistan todos los usuarios. Esto se debe justamente al código que incrustamos dentro del controlador:
if @usuario.save
redirect_to :action => ‘list’
El cual le indica a Rails que en caso de haber guardado exitosamente al usuario, el control se redireccione a la acción list.
Probemos ahora la liga “Back”; la página desplegada deberá ser similar a la siguiente:
Por último, demos click a alguna de las ligas que presenta el nombre de los usuarios, la página web desplegará el detalle de los datos que introducimos anteriormente:
Un punto adicional que vale la pena comentar es que a pesar de que el código RHTML hace sencilla la construcción de vistas, es muy posible que en futuras versiones de Rails este deje de utilizarse debido a que en últimas fechas se han creado nuevos mecanismos que simplifican la manipulación de vistas de manera dramática.
Conclusión
A través de estos 4 artículos tuvimos la oportunidad de revisar el lenguaje Ruby y el framework Rails.
Pudimos comprobar diferentes capacidades que los hacen ser uno de los lenguajes y frameworks más poderosos para desarrollar aplicaciones web de forma extremadamente rápida. Adicionalmente el hecho de ser abiertos, libres y correr en múltiples plataformas los distingue como una de las tecnologías más atrayente de la actualidad.
Esta última entrega finalizó nuestra revisión básica incluyendo el desarrollo
de los controladores y las vistas. Existen temas más avanzados que complementan los mecanismos necesarios para generar una aplicación Rails a nivel empresarial. Temas como el manejo de relaciones entre diferentes objetos de negocio, routers, Ajax, andamios, seguridad y distribución, quedan para una revisión posterior. Sin embargo los elementos hasta aquí presentados permitirán al lector tener las bases mínimas para comenzar a desarrollar y adentrarse en esta novedosa tecnología.
Referencias
[ Thomas David, Fowler Chad, Hunt Andy. “Programming Ruby”. 2nd Edition. The Pragmatic Bookshelf. 2005 ]
[ Thomas David, Heinemeier Hanson David, et al. “Agile Web Development with Rails”. 2nd Edition. The Pragmatic Bookshelf. 2006 ]
[ Black, David A. “Ruby for Rails”. Manning Publications Co. 2006 ]
[ ruby-lang.org/en ]
[ rubyonrails.org ]
[ mysql.com]
[ haml.hamptoncatlin.com ]
Acerca del Autor
Carlos Ortega es consultor en metodologías y prácticas ágiles (XP, TDD, Refactoring, Pair Programming), cuenta con certificaciones en RUP,
OOAD, UML, etcétera. Es Certified ATAM Evaluator y Certified Professional Software Architect ambos avalados por el SEI. Ha colaborado en numerosos proyectos para diversas organizaciones como Banco de México, Elektra, Banco Azteca, Fandelli, Oracle, IMSS, Heinson, Accenture, EDS. Actualmente colabora con Software Ágil, empresa dedicada al tutelaje e implementación de metodologías ágiles (SCRUM, XP, Crystal).
El presente artículo es el cuarto y último de la serie que tiene la intensión de introducir al lector los principales elementos del lenguaje de programación Ruby y del framework Ruby on Rails. En esta ocasión se tratarán los temas del controlador y las vistas.
El Controlador
Contrario a lo que podría indicar el nombre del patrón: MVC, en Rails se aconseja desarrollar primero el controlador antes que la vista. Para lograr esto, Rails echa mano de una clase especial llamada ApplicationController, a través de los siguientes pasos:
a) generar una clase derivada de ApplicationController y
b) manipular con esta clase, a nuestra clase que representa el modelo para lograr el acceso a la base de datos.
Manteniendo la misma filosofía de generación automática de capas, el comado generate permite uitlizar el parametro controller para acceder a la clase ApplicationController, para invocarlo abriremos una sesión en linea de comandos, nos posicionaremos en el directorio railsass e
introduciremos:
path/trabajo/railsass>ruby script/generate controller Usuario
Además de haber creado automáticamente el archivo con el nombre
usuario_controller.rb destinado a contener la clase controladora, también se habrá creado un directorio usuario debajo del directorio views que contendrá los archivos RHTML que manejarán las vistas, un archivo usuario_controller_test.rb para realizar pruebas funcionales y archivo usuario_helper.rb dentro del directorio helper que podrá utilizarse para albergar clases adicionales de soporte que puedan requerirse.
Al abrir el archivo usuario_controller.rb que se encuentra dentro del
directorio app/controllers ,podemos observar que en este se encuentra la clase UsuarioController la cual es derivada de ApplicationController:
class UsuarioController < ApplicationController
end
Ahora bien, los constructores de Rails han diseñado el framework de tal manera que los métodos que se definan dentro de esta clase coincidan con las acciones que se generen en las vistas, es decir, si se desea que se realice un evento específico dentro de las vistas, el código que representa ese evento podrá estar contenido dentro del nombre del método o función que definamos dentro del controlador.
Por ejemplo, supongamos que dentro la vista new.rhtml invocamos al evento agregrar un nuevo Usuario esto, mediante la liga
<%= link_to “Agregar un nuevo Usuario”, {:action => ‘new’}%>
Entonces si deseáramos que al activar esta liga se ejecute un código determinado X, tendremos que definirlo dentro un método o función del controlador cuyo nombre coincida con el nombre de la acción, en este caso new.
El siguiente diagrama intenta ilustrar mejor este mecanismo.
Una vez entendido este concepto podemos proceder a incorporar la parte que manejará al modelo actualizando al controlador:
class UsuarioController < ApplicationController
#---Mostrar la lista de Todos los Usuarios---#
def list
@usuarios = Usuario.find( :all )
end
#--- Crear un nuevo Usuario en Memoria ---#
def new
@usuario = Usuario.new
end
#---Creamos Un Nuevo Usuario ---#
def create
@usuario = Usuario.new( params[:usuario] )
if @usuario.save
redirect_to :action => ‘list’
else
render :action => ‘new’
end
end
#---Mostrar el detalle de Un Usuario---#
def show
@usuarios = Usuario.find( params[:id] )
end
end
Como se puede apreciar a excepción del método show que muestra la lista de todos los Usuarios, hemos creado varios métodos que corresponderían a la funciones CRUD de un objeto de negocio Usuario.
Por otra parte es interesante observar como es que a su vez estos métodos manipulan al Usuario, es decir, dentro de ellos se invocan las diferentes funciones de ActiveRecord, de ahí que el método find de Usuario acepte como parámetro un objeto específico, como una variable de entorno (params[:id) o un símbolo (:all) que representa la condición para regresar todos los objetos Usuario.
Por otra parte, la invocación de método redirect_to resulta en la una nueva llamada a la acción y el refrescado de la página web correpondiente.
Para simplificar nuestra revisión en este momento nos concentraremos solo en un objeto, no tocaremos las relaciones (behaviours)
entre otros tipos de objetos de negocio.
La siguiente étapa es la construcción de las vistas.
La(s) Vista(s)
Como se explicó en la sección anterior, el controlador atiende peticiones de las vistas a través de sus métodos. El nombre de estos métodos coinciden con las acciones a invocarse en las vistas.
Ahora bien, de la misma manera que acontece en otras partes del framework, la convención que los diseñadores de Rails han empleado para definir las vistas, es hacer coincidir el nombre de los archivos que contengan a las vistas, con el nombre de los métodos que representarán a las acciones a invocarse dentro de los controladores.
Por ejemplo, en nuestro caso UsuarioController tiene los métodos list, new y show, por ende generaremos los archivos list.rhtml, new.rhtml,
show.rhtml que serán los que invocaran a estos métodos y se definen
dentro del directorio app/views/usuario, sin embargo a diferencia de lo que sucede con el controlador y el modelo, el comando generate no tiene un parámetro específico para generar los archivos .rhtml que contendrán a las vistas, por esta razón es necesario crearlos a mano.
El siguiente diagrama trata de ilustrar este mecanismo
Un comentario al margen es que existe un mecanismo llamado
scaffolding que permite la generación automática de todas las vistas y un formato homogéneo de las mismas. Sin embargo en esta ocasión no explicaremos este mecanismo con el fin de que el lector conozca y maneje los elementos básicos para manipular vistas.
A continuación se muestra un ejemplo del código de las vistas, en este caso sería de la vista list.rhtml.
<html>
<head>
<h3>
Historia 15 - USUARIOS - Nuevo
</h3>
</head>
<body>
<h1>Agregar un Nuevo Usuario</h1>
<%= start_form_tag :action => ‘create’ %>
<p><label for=”usuario_nombre”>Nombre</label><br/>
<%= text_field ‘usuario’, ‘nombre’ %></p>
<p><label for=”usuario_apellido”>Apellido</label><br/>
<%= text_field ‘usuario’, ‘apellido’ %></p>
<p><label for=”usuario_tipo”>Tipo</label><br/>
<%= text_field ‘usuario’, ‘tipo’ %></p>
<p><label for=”usuario_permisos”>Permisos</label><br/>
<%= text_field ‘usuario’, ‘permisos’ %></p>
<%= submit_tag “Create” %>
<%= end_form_tag %>
<%= link_to ‘Back’, {:action => ‘list’} %>
</html>
Formatos de los archivos de vistas
Al analizar el código RHTML observamos que en estos estan presentes instrucciones HTML y lo que aparenta ser codigo Ruby; en efecto lo es.
Recordemos la arquitectura de Rails: La parte de las vistas esta contenida en archivos .rhtml que son interpetados por el programa ERb, el cual a su vez intepreta, ejecuta y substituye las instrucciones de Ruby y convierte su salida en HTML la cual es entregada al webserver
que finalmente devuelve al browser para su interpretación.
Observemos también que en la vistas, se puede llamar directamente a los objetos de negocio que representan el modelo, esto, sin necesidad de incluir ninguna librería, mas importante aún es recordar que el controlador el responsable de crear este tipo de objetos. Para nuestro caso: @usuario.
Otro punto interesante es el código inmerso dentro de las etiquetas <%= start_form_tag %> … <%= end_form_tag%>, este es una instrucción preconstruida en Ruby que es interpretada por ERb la cual permite el desarrollo de formas complejas en HTML de una forma rápida y sencilla.
Finalmente reinicializaremos nuestro webserver WEBRick (si es que este se encuentra apagado).
ruby script/server webrick
Y arrancaremos el web browser de nuestra preferencia apuntándolo a la siguiente dirección:
http://localhost:3000/usuario/list
La 1ra. vez deberá aparecer una página parecida a la siguiente:
Al darle click a la liga “Agregar Nuevo Usuario” se desplegará en pantalla una forma. Introduzcamos un par de usuarios de ejemplo:
Nombre: Liliana
Apellido: Allen
Tipo: 1
Permisos: rwx rwx rwx
Nombre: Sebastian
Apellido: Coe
Tipo: 2
Permisos: rrr rxx rwx
Y demos click en el boton “Create” al final de la introducción de los datos de cada usuario
Podemos percatarnos que una vez que finalizamos la introducción de cada usuario mediante el botón “Create” la aplicación nos regresa a la página donde se enlistan todos los usuarios. Esto se debe justamente al código que incrustamos dentro del controlador:
if @usuario.save
redirect_to :action => ‘list’
El cual le indica a Rails que en caso de haber guardado exitosamente al usuario, el control se redireccione a la acción list.
Probemos ahora la liga “Back”; la página desplegada deberá ser similar a la siguiente:
Por último, demos click a alguna de las ligas que presenta el nombre de los usuarios, la página web desplegará el detalle de los datos que introducimos anteriormente:
Un punto adicional que vale la pena comentar es que a pesar de que el código RHTML hace sencilla la construcción de vistas, es muy posible que en futuras versiones de Rails este deje de utilizarse debido a que en últimas fechas se han creado nuevos mecanismos que simplifican la manipulación de vistas de manera dramática.
Conclusión
A través de estos 4 artículos tuvimos la oportunidad de revisar el lenguaje Ruby y el framework Rails.
Pudimos comprobar diferentes capacidades que los hacen ser uno de los lenguajes y frameworks más poderosos para desarrollar aplicaciones web de forma extremadamente rápida. Adicionalmente el hecho de ser abiertos, libres y correr en múltiples plataformas los distingue como una de las tecnologías más atrayente de la actualidad.
Esta última entrega finalizó nuestra revisión básica incluyendo el desarrollo
de los controladores y las vistas. Existen temas más avanzados que complementan los mecanismos necesarios para generar una aplicación Rails a nivel empresarial. Temas como el manejo de relaciones entre diferentes objetos de negocio, routers, Ajax, andamios, seguridad y distribución, quedan para una revisión posterior. Sin embargo los elementos hasta aquí presentados permitirán al lector tener las bases mínimas para comenzar a desarrollar y adentrarse en esta novedosa tecnología.
Referencias
[ Thomas David, Fowler Chad, Hunt Andy. “Programming Ruby”. 2nd Edition. The Pragmatic Bookshelf. 2005 ]
[ Thomas David, Heinemeier Hanson David, et al. “Agile Web Development with Rails”. 2nd Edition. The Pragmatic Bookshelf. 2006 ]
[ Black, David A. “Ruby for Rails”. Manning Publications Co. 2006 ]
[ ruby-lang.org/en ]
[ rubyonrails.org ]
[ mysql.com]
[ haml.hamptoncatlin.com ]
Acerca del Autor
Carlos Ortega es consultor en metodologías y prácticas ágiles (XP, TDD, Refactoring, Pair Programming), cuenta con certificaciones en RUP,
OOAD, UML, etcétera. Es Certified ATAM Evaluator y Certified Professional Software Architect ambos avalados por el SEI. Ha colaborado en numerosos proyectos para diversas organizaciones como Banco de México, Elektra, Banco Azteca, Fandelli, Oracle, IMSS, Heinson, Accenture, EDS. Actualmente colabora con Software Ágil, empresa dedicada al tutelaje e implementación de metodologías ágiles (SCRUM, XP, Crystal).
- Log in to post comments