Introducción a Groovy y Grails con Maven: el patrón CRUD

Índice de contenidos

Resumen
1. Introducción a Grails y Groovy
2. Requisitos iniciales
3. Generación del proyecto base mediante el plugin Archetype de Maven
4. Generación del proyecto base desde el arquetipo Maven
4.1. Inicializando la aplicación
4.2. Instalando las plantillas utilizadas por defecto
5. Compilando y probando la aplicación de ejemplo
6. El plugin de Grails para Maven
6.1. Añadir un plugin de Grails al proyecto
7. Introducción al patrón MVC y al CRUD en Grails
7.1. Las plantillas de los formularios
7.2. Un ejemplo sencillo de plantilla modificada list.gsp
8. El plugin de Fields
8.1. Instalación del plugin de Fields
9. Los controladores, la persistencia y el lenguaje Groovy
10. Conclusión

Resumen

En este artículo echaremos un primer vistazo a Grails, el servidor de aplicaciones para el lenguaje Groovy. Además haremos un pequeño ejemplo implementando el patón CRUD (consultas, altas, bajas y modificaciones), que es la base de cualquier aplicación de gestión.

Para hacer esto más sencillo vamos a utilizar como plataforma de desarrollo Maven, ya que nos permite poner en marcha el proyecto de ejemplo en poco tiempo.

1. Introducción a Grails y Groovy

Groovy es un lenguaje interpretado basado en Java al estilo de Ruby y Grails es un servidor de aplicaciones escritas en Groovy al estilo de Ruby on Rails o de PHP con Simphony. Tiene bastantes características interesantes, como es su compatibilidad con Java (podemos usar libremente las clases de java en nuestros proyectos), tipado fuerte y débil y una sintaxis rápida y sencilla, que utiliza bastantes convenios que a aquellos que venimos de Java al principio nos chocan.

Grails es un servidor de aplicaciones que permite ejecutar aplicaciones escritas en Groovy. Algunas de sus características relevantes son:

• Usa convención frente a configuración en para saber qué tiene que hacer. Por ejemplo si una clase Book.grrovy está en grails-app/domain, ya sabe que esa clase declara una entidad del modelo de datos.
• Está preparado para ejecutar aplicaciones que siguen el patrón MVC modelo vista controlador.
• El código fuente es interpretado, basado en ficheros escritos en lenguaje Groovy y páginas web generadas mediante plantillas GSP, que son bastante parecidas a los tradicionales JSPs de J2EE.
• Arquitectura basada en plugins escritos en Groovy. Esto le permite extender su funcionalidad.
• Acceso directo a todos los paquetes java estándar, con soporte para Maven
• Gestor de ciclo de vida basado en Gradle, que es bastante compatible con Maven, aunque no sigue su misma filosofía.
• Soporte nativo para mapeo de bases de datos a Groovy mediante el GORM (basado en Hibernate), con gestión automática de la base de datos subyacente.
• Sistema de generación de modelo, vista y controladores para implementar un CRUD integrado en Grails
• Y por último, las aplicaciones generadas en Grails se pueden empaquetar como WAR y desplegar en un servidor de aplicaciones estándar o en un Tomcat.

2. Requisitos iniciales

El ejemplo lo voy a realizar sobre Ubuntu 14.04 Desktop, que podemos instalar en una máquina virtual usando VirtualBox con mucha facilidad. Ya sabéis, las pruebas con gaseosa y en casa.

3. Generación del proyecto base mediante el plugin Archetype de Maven

Desde Ubuntu, en principio instalamos Maven 3 con este comando:

Si no lo teníamos instalado nos instalará todo el JDK para Java y dejará todo listo para comenzar a crear nuestra aplicación Fácil. Limpio. Rápido…. Pero tiene un problema: en Ubuntu 14.04 nos instala Apache Maven 3.0.5, que no nos vale, ya que el plugin de Grails para Maven requiere Maven 3.1 o posterior. Por ello vamos a instalar una más reciente, por ejemplo Maven 3.2.1 sobre nuestro Ubuntu.

Para instalar una versión más reciente hay que hacer varios pasos:

Ahora editamos el .profile y le añadimos estas líneas al final:

Cerramos la sesión y volvemos a iniciarla, para coger los cambios del .profile. Y probamos el nuevo Maven:

4. Creación del proyecto base desde el arquetipo Maven

Para comenzar creamos un directorio para el proyecto:

NOTA: esta estructura de carpetas está especialmente diseñada para trabajar con Eclipse y Netbeans. Mi consejo es:

• Meter todos vuestros desarrollos en la carpeta workspaces
• Por cada proyecto o desarrollo crear dentro de ella una carpeta workspacenombreproyecto y dentro de ella las carpetas de los proyectos
• Esto último facilita mucho abrir los proyectos en Eclipse y luego importarlos

Mediante el uso del arquetipo Grails para Maven podemos generar de manera sencilla el proyecto base. El arquetipo es generado mediante un plugin de Maven que se descarga automáticamente del repositorio central de Maven. Yo voy a usar en este tutorial una versión concreta del arquetipo, pero se pueden usar otras versiones, es cuestión de ir probando lo que nos funciona.

Nota importante: la versión elegida del plugin es muy importante, ya que no todas funcionan…. Por ejemplo yo he probado la versión 2.3.8 y con pruebas sencillas no he logrado levantar la aplicación con la configuración por defecto. La versión 2.2.4 inicializa y ejecuta la aplicación sin problemas, por lo que para tomar contacto con Grails es la apropiada.

Podemos saber la lista de versiones disponibles consultando directamente el directorio del plugin en el repositorio central de Maven. ¿no sabes cómo buscarlo? La ruta para encontrar un artefacto o plugin en el repositorio central de Maven es:

http://repo1.maven.org/maven/GROUP-ID/ARTIFACT-ID

Donde:

• GROUP-ID es el groupId convirtiendo los puntos por barras d, por ejemplo si el gropuId es org.grails, el GROUP-ID será org/grails
• El ARTIFACT-ID es el artifactId que tenemos que usar.
• NOTA: esto vale para CUALQUIER dependencia Maven

Y el comando a ejecutar para este arquetipo es:

Si no te has dado cuenta ya, la ruta del arquetipo en Maven es:

https://repo1.maven.org/maven2/

Y veremos una carpeta por cada versión del plugin.

4.1. Inicializando la aplicación

Tras la ejecución del plugin de archetype lo único que tenemos en grailsdemo es un pom.xml y una carpeta src casi vacía, salvo el web.xml que hay en src/main/webapp/WEB-INF. Parece poco, pero como siempre hay que terminar de trabajar en Maven. Inicializamos el proyecto.

4.2. Instalando las plantillas utilizadas por defecto

Este paso es un poco curioso. Lo que hace es instalar las plantillas en la carpeta /src/templates que luego se usan para generar los GSPs. Conviene hacerlo en este momento, pues luego cuando se instala el plugin de Fields ya no se puede hacer (por lo menos a mi me ha dado problemas):

El uso de las plantillas lo veremos más adelante.

5. Compilando y probando la aplicación de ejemplo

Ejecutando la aplicación:

Podría ser que el Tomcat7 (puede ser otro servidor o aplicación) ya estuviera ocupando el puerto, por lo que debemos primero pararlo:

Y vemos el resultado:

6. El plugin de Grails para Maven

Si instalamos Grails como servidor de aplicaciones y entorno de generación de aplicaciones, hay un montón de acciones que se pueden ejecutar desde Grails. Estas acciones suelen tener un equivalente Maven para ser ejecutadas desde el plugin de Maven.

En la documentación de Grails está toda la documentación del plugin de Grails para Maven… pero ojo, es bastante incompleta. Hay que averiguar muchas cosas mediante ensayo y error.

Para saber qué propiedades podemos definir antes de llamar a una de las tareas del plugin de Grails usaremos este comando:

Si queremos la ayuda de un goal complete usamos el parámetro goal:

Por ejemplo para grails:create-domain-class:

Error importante: si al ejecutar un commando de Grails Maven retorna un error de este estilo:

Es muy probable que nos falte definir parámetros para el comando de Grails. En Grails, se pedirían por pantalla dichos parámetros. Pero dado que la versión evaluada tiene algunos parámetros con el modo interactivo desactivado, hay que definirlos antes de ejecutar el goal del plugin de Grails.

6.1. Añadir un plugin de Grails al proyecto

En Grails hay muchos plugins disponibles para realizar un montón de tareas. La lista completa de plugins disponibles la podemos generar con:

Para añadir el plugin de Grails, simplemente se mete en el pom.xml la dependencia del plugin, por ejemplo:

Al intentar ejecutar la aplciación, se descargará e instalará el plugin de Grails.

7. Introducción al patrón MVC y al CRUD en Grails

Grails está preparado para crear aplicaciones que siguen el patrón MVC de manera sencilla. El Proceso es el siguiente:

1. Creamos el modelo. Para ello vamos a definir las entidades mediante clases Groovy que definirán los datos que se van a persistir en la base de datos
2. Luego generamos los controladores asociados a dichas entidades. Se generarán automáticamente las acciones necesarias para implementar el patrón CRUD (Consltas, altas, bajas y modificaciones)
3. Luego generamos las vistas que podrán mostrar la información de dicha entidad

Generemos una entidad simple: Book:

Y ahora veremos que se ha creado una clase groovy en la carpeta de clases del dominio grails-app/domain/grailsdemo

Vamos a generar el controlador (ojo con el nombre de la entidad, ya que las genera dentro del paquete grailsdemo)

Y ahora generamos la vista:

Los ficheros generados son:

• en grails-app/views/book/
• create.gsp
• edit.gsp
• _form.gsp
• list.gsp
• show.gsp
• En grails-app/controllers/grailsdemo/
• BookController.groovy
• En grails-app/domain/grailsdemo/
• Book.groovy

Las vistas generadas son GSPs, que son parecidos a los JSPs estándares, pero incluyen etiquetas Groovy para generar los elementos de la vista.

El controlador está escrito en Groovy, por lo que hay que entender algunos de los conveniso del lenguaje Grroovy para ver cómo funciona.

Ahora ejecutamos de nuevo la aplicación con $ mvn grails:run-app y al abrir el navegador ya aparece el nuevo controlador.

Pinchamos en el controlador:

Y si pinchamos en Crear Book:

Ahora vamos a añadir nuevos campos a la entidad. Modificamos el fichero Book.groovy

Y regeneramos las vistas con:

Al ir a crear un nuevo libro aparecen ya los campos.

7.1. Las plantillas de los formularios

¿Cómo genera Grails los ficheros GSPs cuando usamos grails:generate-views? El misterio está en los ficheros de plantillas. Pero la plantilla es a su vez un GSP, luego el motor de Grails genera un GSP a partir de un GSP de plantilla. El proceso exacto es bastante curioso. Para explicarlo mejor vamos a ver una plantilla y un GSP generado a partir de ella:

Ahora vemos el fichero generado:

Observar que entre otras cosas:

• Los \$ se cambian por $ en el fichero GSP generado
• Los {variable} se sustituyen por su valor en el GSP generado
• Se usan sentencias de control g:if y g:each para generar elementos en el GSP generado.

Este último punto es muy importante, ya que si queremos personalizar un GSP generado hay que modificar las plantillas y añadir las exclusiones o código a medida que necesitemos… en la propia plantilla.

Una pregunta curiosa. Por defecto ¿cuántas columnas tiene como máximo un listado estándar en Grails?

Por cierto, ¿cuál es el orden de las columnas en los listados?

7.2. Un ejemplo sencillo de plantilla modificada list.gsp

Os voy a mostrar una plantilla list.gsp que incluye elementos a medida:

8. El plugin de Fields

En Grails, al mecanismo utilizado para generar el patrón CRUD se le llama scaffolding (andamiaje). Este mecanismo utiliza un sistema de plantillas para gerarlas vistas.

Estas plantillas analizan la clase entidad del dominio y generan la vista durante la etapa «grails:generate-views».

Pero el sistema de plantillas utilizado por defecto es muy básico. Es recomendable utilizar el plugin Fieds de Grails para tener más flexibilidad a la hora de generar las vistas.

8.1. Instalación del plugin de Fields

Se mete la dependencia en el pom.xml y se vuelve a compilar:

Luego hacemos $ mvn grails:run-app para que se instale el plugin de fields.

Si volvemos a intentar regenerar la vista veremos cómo se descarga e instala el plugin automáticamente.

Para instalar las plantillas del plugin hay que hacer:

Las plantillas se generan en /src/templates/scaffolding

El plugin de fields nos permite modificar el comportamiento de cada campo, pudiéndole asignar a un campo un trozo de código simplemente ubicando el código de plantilla en el lugar adecuado. Por ejemplo podemos modificar el campo fechaPublicacion de la entidad Book. Para ello creamos el fichero de plantilla de dicho campo en el lugar adecuado:

Os dejo como tarea:

• Instalar el plugin richui
• Añadir la etiqueda al principio del fichero src/templates/scaffolding/create.gsp

• Regenerar la vista
• Ver que se genera un nuevo campo fecha de publicación

Ayuda: Esta es la dependencia que yo he usado:

9. Los controladores, la persistencia y el lenguaje Groovy

Para el patrón MVC necesitamos un modelo, que es nuestra entidad Book, un conjunto de vistas, que son los GSP generados por Grails y nos queda nada más analizar el contolador, que es una clase Groovy.

Ya que hemos generado el controlador, listemos su contenido:

¿Cómo funciona el controlador? Es como en otros frameworks MVC. La ruta solicitada por el navegador comienza por el nombre del controlador y la acción solicitada, y los parámetros añadidos a la ruta estarán disponibles dentro del controlador. Dentro del controlador se debe invocar a un método. Así http://localhost:8080/grailsdemo/book/ invoca a la acción por defecto, que es index() y ésta a su vez redirige al list(), y http://localhost:8080/grailsdemo/book/create invoca a la acción créate del controlador BookController.groovy

Si observamos las acciones encontraremos detalles importantes al estar usando Groovy, que hay que tener en cuenta si venimos de Java:

• El estilo de escritura es muy simple, no hay muchos «;»»
• Groovy tiene más operadores que Java, como ?. y otros.
• Las variables en Groovy pueden ser débil o fuertemente tipadas.
• Al estilo de javascript, las variables no tipadas se definen con «def»
• A una variable se le puede asignar un valor o un trozo de código. Esto último es lo que se denominan «closures» en Groovy.
• Además es muy normal definir la «closure » e invocarla a la vez, como por ejemplo en estre fragmento de código:

• Todos los métodos devuelven siempre un valor, que el valor de la última sentencia o expresión ejecutada
• Cuando se ejecuta un método del controlador, la variable params contiene los parámetros de la petición.
• Una lista se crea simplemente encerrando un conjunto de valores entre corchetes cuadrados: [ «cadena1», «cadena2», «cadena3»]
• Un mapa se crea simplemente encerrando un conjunto de pares clave:valor entre corchetes cuadrados: [nombre: «Diego», apellido:»Rojo» ]
• Si el método del controlador devuelve un mapa, éste se añadirá al conjunto de variables disponibles por la vista, como en el método edit() del controlador de Book
• Ojo con las vistas, ya que los GSPs se parecen a los JSPs estándares de java, pero son más potentes, ya que las expresiones ${ } admiten cualquier expresión Groovy, incluso llamadas a métodos.
• Todo el acceso a la base de datos lo haremos a través de GORM, que es el mapeador de Grails, basado en Hibernate. Además GORM utiliza un avanzado sistema de

«proxis dinámicos» que simplifica la ejecución de consultas sencillas, como los típicos findByAutor()

• Nota: todo el sistema de persistencia por defecto trabaja en memoria, pero se puede guardar en una base de datos simplemente cambiando el DataSource.groovy

10. Conclusión

En este tutorial hemos realizado una presentación de Grails, usando como herramienta de desarrollo simplemente Maven. Hemos visto entre otros:

• Como se crea una aplicación en Grails
• Como se crea un patrón CRUD en Grails
• Una ligera introducción al patrón MVC y su implementación en Grails
• Algunas técnicas de Grails y Groovy

Y ahora llega la pregunta del millón ¿cuándo debo usar Grails en vez de Java con JSF y los frameworks estándares?

• Para un desarrollo corto, con un modelo de datos sencillo y un flujo de pantallas basado en CRUDs, Grails nos da la oportunidad de desarrollar la aplicación en poco tiempo, si lo dominamos.
• Realmente desarrollar en Groovy también tiene su propia curva de aprendizaje. Se pueden hacer cosas bastante interesantes en poco tiempo, pero adaptar el estilo visual de la aplicación a lo que a nosotros nos gusta lleva su tiempo.
• Si el desarrollo es largo, los frameworks de Java suelen facilitar los desarrollos (por ejemplo usando Primefaces o similares) y es algo a lo que la mayor parte de desarrolladores Java están ya acostumbrados.