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.
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:
Su uso en un gsp sería:
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.