Trazas en un gsp de Grails

Disponer de información para tratar de averiguar la causa de un problema es vital para poder resolverlo rápidamente. Para ello existen los sistemas y librerías de trazas que permiten a la aplicación sacar mensajes a un archivo para su consulta posterior ya sea en Java, Javascript o seguro que otros lenguajes.

En el caso de Grails inyecta en varias entidades como controladores, servicios y clases de dominio el objeto log con el que se pueden emitir las trazas con el nivel que deseemos.

	log.debug('Esto es un mensaje de depuración')
	log.info('Esto es un mensaje de información')
	log.error('Esto es un mensaje de error')

view raw Ejemplo.groovy hosted with ❤ by GitHub

Sin embargo, a veces nos puede resultar interesante también sacar alguna traza en los gsp para conocer que es lo que se ha emitido, especialmente si se trantan de gsp que contienen lógica de negocio con etiquetas g:if especialmente complejas. Tener mucha lógica en las vistas es una práctica no recomendada para evitar el código espagueti en los gsp que en el mantenimiento puede causarnos problemas al posiblemente tener esa lógica duplicada en varias zonas diferentes de la aplicación. Los frameworks que usan un sistema de plantillas donde por un lado están los datos y por otro la plantilla sin una posibilidad propia («built-in») de extraer esa lógica a una entidad externa suele ser habitual. Esto nos puede obligar a precalcular todas esas condiciones y pasarlas a la visa como datos lo que nos exige conocer previamente en el controlador exactamente que datos necesita la vista y mantener el código de dos archivos sincronizados o crear métodos con esa lógica en los objetos que le pasamos a la vista como podrían ser en las entidades persistentes de dominio.

Una forma de emitir trazas desde un gsp es incluir un scriptlet que obtenga un logger y posteriormente hacer log.debug. Pero si hacemos esto en muchos gsp y de forma habitual es mejor hacerlo con un tag ya que el código de los gsp nos quedará más limpio y será un poco más sencillo además de tener centralizado en un único sitio el tratamiento de los logs de todos los gsp. Ese tag necesitará recibir el nivel de la traza y el mensaje de la traza al menos. Podría ser como lo siguiente:

	package es.com.blogspot.elblogdepicodev.grails.taglib;
	import org.apache.log4j.Level
	class UtilidadesTagLib {
	static namespace = 'util'
	def xlog = { attrs, body ->
	def level = (attrs.level)?Level.toLevel(attrs.level):Level.DEBUG
	def message = (attrs.message)?:body()
	def token = (attrs.token)?:''
	message = "[${token}] ${message}".toString()
	//
	switch (level) {
	case Level.FATAL:
	log.fatal(message)
	break;
	case Level.ERROR:
	log.error(message)
	break;
	case Level.WARN:
	log.warn(message)
	break;
	case Level.INFO:
	log.info(message)
	break;
	case Level.DEBUG:
	log.debug(message)
	break;
	case Level.TRACE:
	default:
	log.trace(message)
	break;
	}
	}
	}

view raw UtilidadesTagLib.groovy hosted with ❤ by GitHub

Su uso en un gsp sería:

	<util:xlog level="info" message="Hola mundo"/>
	<util:xlog level="info" token="mensaje">Hola mundo</util:xlog>

view raw ejemplo.gsp hosted with ❤ by GitHub

Y este sería el caso para el framework grails y su parte de visualización con gsp, para otros frameworks que probablemente tengan otro sistema para la parte de la vista nos puede ser útil una solución con similar funcionalidad.