Desde que empezó el Google Summer of Code no he explicado exáctamente qué es y el por qué de mi proyecto, ahora que veo cerca la primera versión (a falta de un problema con las urls que mapean a vistas) ya empieza a ser hora de hacerlo.
La cuestión es que Grails no tiene el comportamiento típico de include, tiene el tag render que es parecido(para el caso de un template estático sería igual) pero se orienta al principio Don't Repeat Yourself en la vista, por lo que al render hay que pasarle los objetos o colecciones de objetos que se utilizarán para renderizar el template.
Esto puede llevar a un problema de repetición de código en los controllers, por lo que aquí rompemos el Don't Repeat Yourself, siendo sensibles a futuros cambios. Ésto no quiere decir que el render no valga, en mi opinión para conseguir no repetir código dependiendo de los casos, lo mejor es combinar ambos comportamientos. Aunque el problema de la repetición de código se puede solucionar con nuestras propias librerías de tags, que con Grails son sencillas de crear, pero pienso que debería ser todavía más sencillo y limpio utilizando una acción de un controller que además podríamos reutilizar para por ejemplo peticiones XMLHttpRequest.
Metiéndonos ya en el uso del plugin, existen dos formas de hacer el include, la forma clásica con el tag includeURL:
<g:includeUrl url="/prueba/show?param=value"/>
Los posibles valores de url pueden ser tanto urls que mapean a controllers/acciones/vistas de nuestra aplicación grails, como a recursos estáticos como puede ser un html plano o un fichero de texto que se encuentren en el mismo contexto. Para el caso de las urls mapeadas, los parámetros se pueden pasar por los posibles valores de la url mapeada tipo REST como con parámetros de la request de los de siempre.
Y la segunda forma es para mi es la forma recomendada para los caso de hacer un include a acciones de nuestros controllers, includeController:
<g:includeController controller="prueba" action="show" params="[param:'value']"/>
Al que se le pasa el nombre del controller, acción y mapa de parámetros. Hay que decir que por la convención de nombres, en el caso de prueba buscará en controlador PruebaController. La recomendación es simplemente por la probabilidad mucho mayor de una cambio de mapeo de url que del nombre de un controller, cada uno verá de qué manera prefiere hacerlo ;).
Hablando ya sobre la experiencia desarrollando éste plugin, la verdad que me esperaba que fuera más sencillo de desarrollar, estaba claro que sería necesario un wrapper del response para hacer el include con el RequestDispatcher. Al final he tenido que escribir también un wrapper para el request y re-escribir parte del filtrado del mapeo de urls de grails, al ser la misma petición y no estar contemplado este comportamiento anteriormente, ha habido que hacer un poco de trabajo extra investigando el código del framework en cuanto a mapeo de urls y hacer mucho debug por no conocer el código (gracias IDEA + JetGroovy! :)).
A ver si dejo una versión estable de éste plugin en las próximas semanas, y comienzo a colaborar con el plugin de Java Content Repository para poder trabajar con ésta especificación de una forma más o menos parecida a como se usa GORM con Hibernate por debajo.
