Grails

Para comprobar el funcionamiento de las plantillas en Grails, vamos a crear una que nos permita mostrar un pie de página en toda nuestra aplicación que sustituirá al que Grails ha creado por nosotros. Como es una plantilla común a toda la aplicación, la almacenaremos en el directorio grails-app/views/common y la vamos a llamar _footer.gsp y su contenido será algo parecido a esto:

Una vez creada la plantilla, necesitamos poder incrustarla en nuestro proyecto. Para ello, vamos a modificar el layout main.gsp para incluir la llamada correspondiente a esta plantilla. Nosotros vamos a añadir esta plantilla justo después de la etiqueta <g:layoutBody/>, quedando de esta forma:

Para pintar la plantilla correspondiente hemos utilizado la etiqueta de Grails g:render y como habrás podido comprobar, no es necesario poner ni el subrayado bajo ni la extensión gsp en el parámetro template, puesto que Grails ya lo hace por nosotros.

Nuestra aplicación ya dispone de un pie de página con la información sobre los creadores de la aplicación. Pero, ¿qué pasa si queremos modificar la apariencia de como se muestra este pie de página para por ejemplo centrar el texto? Esto lo conseguiremos editando la información relativa a los estilos de la página (CSS). Las hojas de estilos de las aplicaciones en Grails se encuentran en el directorio grails-app/assets/stylesheets/, y concretamente tenemos un archivo llamado main.css. Lo que vamos a hacer a continuación es modificar la clase correspondiente al pie de página (.footer). Abrimos la hoja de estilos main.css y localizamos la clase .footer para dejarla de la siguiente forma.

La primera plantilla que hemos creado no nos ha supuesto mucha complicación y era muy sencilla de implementar, pero al menos nos ha servido como introducción al sistema de plantillas de Grails y a comprender como se renderizan estas plantillas en el sistema. La segunda plantilla que vamos a implementar nos va a complicar algo más la vida.

Aunque nuestra aplicación todavía no tiene el concepto de usuario (es algo que añadiremos en la sesión 7), esta plantilla será la encargada de mostrar un enlace indicando la palabra login para que cuando los futuros usuarios hagan clic sobre ella, aparezca un formulario donde el usuario podrá identificarse en el sistema. Ahora bien, ¿qué pasa si el usuario ya se ha identificado? Pues lo que se hace habitualmente es modificar esa primera línea para que en lugar de mostrar un enlace con la palabra login, se muestre una línea con el nombre completo del usuario en cuestión y un enlace para que abandone el sistema de forma segura. Eso es lo que vamos a hacer con esta segunda plantilla.

En primer lugar, vamos a modificar el archivo grails-app/views/layout/main.gsp para que en la parte superior de la aplicación, aparezca un encabezado que definiremos posteriormente. El archivo main.gsp quedaría así:

Si intentas actualizar ahora la aplicación, verás como Grails nos devuelve un error y esto es debido a que todavía no hemos creado la correspondiente plantilla _header.gsp, así que antes de continuar vamos a crearla en el directorio grails-app/views/common/, puesto que es una plantilla que se utilizará a lo largo de toda la aplicación independientemente de la clase que estemos utilizando en cada momento. Vamos a ver el contenido de esta nueva plantilla y luego lo comentamos más ampliamente.

Si actualizamos ahora la aplicación en el navegador, veremos como el enlace con la palabra Login queda a la izquierda, lo que no es lo habitual en las aplicaciones web, donde suele aparecer casi siempre en la parte superior derecha de la pantalla. Para solucionar esto, volvemos a editar los estilos de nuestra aplicación y le añadimos las siguientes entradas:

Ya tenemos alineado a la derecha el texto con la palabra Login, que además, aparecerá en cualquier página de la aplicación. Antes de continuar, vamos a explicar el contenido del archivo grails-app/views/common/_header.gsp. Podemos comprobar como se hace una comprobación para saber si el usuario actual se ha identificado o no en nuestro sistema. Para realizar esta comprobación utilizamos la etiqueta <g:if>, a la que se le pasa el parámetro test con la variable ${isUserLoggedIn} (variable que todavía no existe). En caso de que esta variable esté ya definida (el usuario ya se ha identificado en el sistema), se mostrará su nombre y apellidos seguido de un enlace para que abandone la aplicación de forma segura. En caso contrario, se le mostrará un enlace con la palabra Login para que se identifique. En ambos casos, se utiliza la etiqueta <g:link> que permite crear enlaces que apunten a una determinada acción de un controlador, tal y como veremos más adelante.

Si ahora hacemos clic sobre Login, veremos como Grails nos devuelve un error del tipo 404, puesto que no hemos definido nada para que la aplicación actúe en consecuencia. Lo dejaremos así hasta que nuestra aplicación soporte usuarios que veremos en la sesión de Spring Security.

En GSP podemos utilizar podemos utilizar los símbolos <% %> de la siguiente forma

Y de forma similar podemos acceder a esa variables con

Dentro del alcance de una página GSP, tendremos a nuestra disposición una serie de variables predefinidas, que son:

Utilizando los símbolos <% y %> vamos a poder realizar bucles:

así como comprobaciónes lógicas:

Las páginas GSP soportan además algunas directivas típicas de las JSP tales como importar clases:

o incluso las directivas para especificar el tipo de contenido de la página visualizada:

La sintaxis vista en el punto anterior que utiliza los símbolos <% y %> sin embargo no es tan utilizada debido a la existencia de las expresiones GSP, que son similares a las expresiones JSP EL y tienen la forma ${expresion}:

Estas etiquetas nos permitirán realizar comprobaciones del tipo si-entonces-sino.

Son utilizadas para iterar a través de colecciones de datos o hasta que una determinada condición se evalúe a falso.

Nos servirán para asignar valores a variables.

Crean enlaces a partir de los parámetros pasados.

Las utilizaremos para crear nuestros propios formularios HTML.

Permite renderizar las páginas web de nuestras aplicaciones utilizando las plantillas.

Se utilizan para mostrar errores y mensajes de advertencia.

El primer ejemplo de etiqueta que vamos a crear será una etiqueta que permita la inclusión de archivos de funciones javascript en el código de nuestras páginas GSPs. Para ello definimos un método en la nueva clase TodoTagLib con el siguiente contenido:

La creación de la etiqueta necesita como parámetro los atributos de la misma. En este primer ejemplo, sólo vamos a utilizar un atributo que será el nombre del archivo javascript que queremos invocar en nuestra página GSP.

Una vez creada la etiqueta, para realizar la invocación de la misma en las páginas GSP utilizaremos el siguiente código.

Para invocar la nueva librería creada se utiliza el namespace genérico <g>. Sin embargo, Grails nos permite crear nuestro propio espacio de nombres para que el código generado sea sencillo de leer. El espacio de nombres que vamos a utilizar será me, acrónimo de mis etiquetas. Para ello debemos definir una variable estática al inicio de la clase TodoTagLib llamada namespace e indicándole el valor del nuevo espacio de nombres, tal y como aparece en el siguiente fragmento de código.

De esta forma, en nuestras páginas GSP ya no tendríamos que utilizar <g:includeJs script="miscript"/> sino que podríamos emplear <me:includeJs script="miscript"/>, con lo que la persona que lea el código podrá detectar que esa etiqueta es una etiqueta propia de la aplicación.

En ocasiones, es posible que sea necesario referenciar a nuestras etiquetas desde controladores o desde otras etiquetas y no nos va a ser posible referenciar a estas etiqueta de la forma habitual. En este caso deberíamos llamar a la etiqueta de la siguiente forma:

En este ejemplo, en primer lugar imprimimos un log para saber que estamos renderizando una image y después utilizamos una librería de etiquetas disponible en el plugin asset-pipeline que nos permite renderizar imágenes de forma optimizada en todos los entornos.

Con Grails también es posible crear etiquetas lógicas que evalúen una cierta condición y actúen en consecuencia en función de dicha evaluación. El siguiente ejemplo es una etiqueta que comprueba si el usuario autenticado es un administrador. El siguiente método realiza esta comprobación y en caso de ser cierto, se mostraría el contenido encerrado entre la etiqueta.

En esta ocasión, la nueva etiqueta no sólo recibe el atributo attrs sino que también necesita del atributo body, que se refiere a aquello que esté encerrado entre la apertura y el cierre de la etiqueta. El método comprueba si el usuario pasado por parámetro es un administrador. En la página GSP correspondiente deberíamos indicar el siguiente código.

Grails ofrece la posibilidad de generar código HTML de forma muy sencilla gracias a un Builder conocido como MarkupBuilder. Para comprobar el funcionamiento de este Builder, vamos a crear una nueva etiqueta que imprima un enlace cuyo atributo href coincida con el título. Por ejemplo, para imprimir un enlace a la página de Google, normalmente debemos incluir el código <a href="http://www.google.com">http://www.google.com</a>. Con esta etiqueta que vamos a crear nos ahorraremos escribir la dirección url dos veces.

En primer lugar creamos un nuevo método en el archivo TodoTagLib.groovy y lo llamaremos printLink(). Este método utilizará el MarkupBuilder e imprimirá un enlace con el valor del atributo href igual al contenido.

Ahora en la vista podemos añadir una etiqueta como <me:printLink>http://www.google.com</me:printLink>, la cual será traducida al código HTML <a href="http://www.google.com">http://www.google.com</a>.

Como veíamos anteriormente, los controladores en Grails se ubican en el directorio grails-app/controllers. Si recordamos la imagen donde se explicaba el proceso típico de una aplicación que utiliza el patrón Módelo Vista Controlador, los controladores se encargan básicamente de dirigir las llamadas a nuestra aplicación y de ponerse en contacto tanto con las clases de dominio, las vistas y los servicios para ponerlos de acuerdo.

Para analizar el formato de los controladores en Grails, veamos uno cualquiera de los generados en la sesión anterior, como por ejemplo TodoController.groovy:

En primer lugar vemos que se especifica mediante la anotación @Transactional la transaccionalidad de todos los métodos del controlador. En la siguiente sesión aprovecharemos para hablar sobre los diferentes niveles de transaccionalidad cuando veamos los servicios en Grails.

La variable estática allowedMethods nos permite especificar para determinados métodos de nuestros controladores, el tipo de petición aceptada. En el caso del controlador generado vemos como el método save() sólo puede ser procesado por una petición de tipo POST, las actualizaciones por peticiones de tipo PUT y por último los borrados sólo serán válidos cuando se hagan mediante una petición de tipo DELETE.

Los parámetros pasados a los métodos serán mapeados directamente por Grails a partir de los parámetros pasados en la petición. Por ejemplo, si efectuamos la petición http://localhost:8080/todo/todo/index?max=20, el parámetro max de la petición con valor 20 será pasado como parámetro al método index.

Como has podido comprobar en el ejemplo anterior, no es necesario especificar lo que van a devolver los método de los controladores con lo que podemos dejar que sea Grails quien se encargue de definirlo especificando la palabra reservada def.

Comentar también que en la últimas versiones de Grails se ha añadido el método respond que provocará una salida diferente en función de la petición HTTP efectuada. Por ejemplo, si abrimos un terminal y ejecutamos:

veremos que la salida del método será en formato json, mientras que si ejecutamos

veremos que la salida del método será en formato xml, mientras que si desde un navegador vamos a la dirección http://localhost:8080/todo/todo/index, Grails renderizará una página html siguiendo una serie de convenios que veremos a continuación.

Además, cada controlador en Grails tiene un método por defecto que sigue las siguientes reglas:

Los ámbitos (scopes) son una serie de objetos que nos permitirán almacenar variables en una aplicación en Grails. Tenemos los siguientes ámbitos:

Las vistas serán las encargadas de mostrar al usuario aquello que el controlador quiera mostrar. Si echamos un vistazo a los métodos del controlador TodoController nos costará entender esa relación pues apenas se hace mención a ninguna vista en este controlador. Esto es debido a que cuando no se especifica de forma explícita que vista renderizar, Grails utiliza lo que comentábamos en la sesión anterior al respecto de "convención sobre configuración" y directamente trata de renderizar una vista que coincida con el patrón nombre-del-controlador/nombre-del-método.gsp, con lo que por ejemplo, en el método

al no haber indicado ninguna vista en el método respond(), Grails renderizará la vista ubicada en el directorio grails-app/todo/show.gsp. Como comentábamos anteriormente, el método respond() se encarga de decidir como renderizar la salida pero si tiene que renderizar una vista en HTML, bien buscará una siguiendo el patrón mencionado o bien le podemos pasar una de forma de implícita, como por ejemplo vemos en el método save() del controlador TodoController

Sigamos con la relación entre vistas y controladores. Si vemos las vistas y los métodos del controlador TodoController generados automáticamente por el scaffolding estático nos daremos cuenta rápidamente que cuatro de esos métodos tienen vistas asociadas (index, create, edit y show) mientras que otros tres no tienen ninguna vista asociada (save, update y delete). Esto es debido a que estos tres últimos métodos serán los encargados únicamente de crear, actualizar o eliminar una tarea y serán los otros métodos los encargados de renderizar las vistas correspondientes.

Si abrimos la vista todo/create.gsp veremos que el formulario se debe procesar con la acción save()

con esto conseguimos que al enviar el formulario, el encargado de procesarlo sea el método save().

Veamos ahora todo el proceso de creación de una tarea. Si arrancamos nuestra aplicación y accedemos en el navegador a la dirección http://localhost:8080/todo/todo/create, el método que sale al rescate es TodoController.create(). Este método con una sóla línea de código es capaz de renderizar una vista con una tarea asociada, que en principio tendrá todos sus campos vacios.

Este método renderizará la vista todo/create.gsp y le pasará una variable llamada todoInstance que contendrá una tarea con sus campos vacios.

Si abrimos ahora la vista todo/create.gsp vemos como esa vista únicamente llama a la plantilla todo/_form.gsp que es la que contiene los elementos de formulario necesarios para crear una tarea.

Una vez el usuario envía la información, el método encargado de procesar esa petición será TodoController.save()

Pongámonos en el caso en que no hayamos completado correctamente todos los campos requeridos. Si ésto sucede, el método volverá a renderizar la vista todo/create.gsp con los errores que se hayan producido.

En caso de que todo vaya bien, se almacena la nueva tarea

y se trata de renderizar el resultado en función del tipo de petición realizada. En caso de que hayamos envíado un formulario se redirige la aplicación para mostrar esa tarea recien creada con una variable de tipo flash para mostrar un mensaje indicando que la tarea se ha creado correctamente.

Cuando hacemos esta redirección Grails buscará el método show() y lo renderizará. Este método pintará en el navegador la vista todo/show.gsp. Esta vista, como prácticamente cualquier vista, tiene un fragmento de código que comprueba la presencia de una variable de tipo flash para actuar en consecuencia. En este caso simplemente mostrará el mensaje que hemos completado en el método save() del TodoController.

Si en lugar de haber envíado un formulario a través de una página HTML, la petición es de cualquier otro tipo, se trata de renderizar una salida acorde al tipo de petición.

Si por ejemplo lanzamos desde la terminal el siguiente comando

la aplicación nos creará una nueva tarea y nos devolverá el resultado en formato json. Si por el contrario ejecutamos

Con esto hemos podido comprobar como Grails con muy pocas líneas de código es capaz de generar una aplicación que será capaz de responder al cliente de varias formas con lo que podemos tener una aplicación multiplataforma todo integrado en el mismo código fuente.

Si hacemos un rápido test de usabilidad en nuestra aplicación veremos que cada vez que necesitamos editar o eliminar una tarea, tenemos que hacer dos clicks sobre la misma, uno para ver la tarea y otro para editarla. Vamos a solucionar este problema de usabilidad modificando el listado de las tareas para añadir una nueva columna a la izquierda de cada tarea para mostrar dos opciones, una para editar y otra para eliminar una tarea.

Aprovecharemos también para eliminar las columnas Description y Reminder Date del listado de las tareas.

Vamos a crear una etiqueta que nos permita, a partir de un valor booleano, imprimir un icono u otro. La etiqueta se llamara printIconFromBoolean y únicamente recibirá como parámetro el atributo value. Modifica también el namespace de la librería creada para que podamos a ella a través del namespace todo con lo que para llamar a nuestra etiqueta tendríamos que ejecutar algo como:

Y deberíamos imprimir algo parecido a esto:

Sería aconsejable que utilizaras el método image() de la librería de etiquetas del plugin asset pipeline. Aquí tienes un ejemplo:

Cuando deseamos eliminar una etiqueta, al hacer click sobre el botón eliminar se nos muestra un mensaje en Javascript para confirmar si realmente queremos eliminar esta etiqueta. Vamos a modificar este sistema para que en lugar de mostrar un mensaje en Javascript, nos muestre una nueva página para pedir confirmación. Esto nos permitirá añadir algo más de seguridad en lo que el usuario está realizando ya que podemos mostrar un mensaje de alerta más evidente, como por ejemplo éste: