Presentación sobre Apache Tapestry

El 10 de febrero tuve la oportunidad de dar una charla, la primera, sobre Apache Tapestry para el equipo de desarrolladores de la empresa en la que trabajo. Que en el equipo de desarrollo tengamos la posibilidad de vez en cuando dedicar un par de horas para juntarnos y compartir conocimiento es una buena iniciativa ya que siendo ya un equipo bastante grande de personas y con un nivel técnico elevado cada uno tiene un conocimiento que los demás pueden estar interesados en conocer al menos a nivel superficial, es motivador tener estas oportunidades.

Fue una charla simplemente como cultura general ya que el framework y el lenguaje que usamos como pila tecnológica es Grails y Groovy y eso es complicado que cambie. Otro motivo fue poder compartir el conocimiento de este framework para el desarrollo de aplicaciones y páginas web que a mi me gusta mucho. Si estás suscrito al feed de mi blog ya conocerás que de vez en cuando publico alguna entrada comentando algún aspecto sobre él (tengo ya algunas preparadas y otras en mente) y si estás suscrito desde hace unos meses conocerás que escribí un libro. La charla fue para comentar los «porque» alguien podría elegir este framework y no tanto el «como» se hacen las cosas en él, para esto último ya esta el libro PlugIn Tapestry, otra documentación y la propia documentación del proyecto.

Probablemente la charla podría haberla explicado mucho mejor, fue lo mejor que fui capaz. También ya después de unas horas me dí cuenta de los detalles menores pero interesantes que se me pasaron comentar, unos cuantos. Pero teniendo en cuenta que es de las primeras charlas técnicas que doy, en general quedé satisfecho y por lo menos me servirá de experiencia para las siguientes. Dar una charla require tanto o mas esfuerzo que crear una entrada en el blog. Requiere crear una presentación, incluir en ella la información relevante que se quiere comentar según el objetivo y tener en cuenta el público al que va dirigida, poner la información de una forma que explique de forma coherente lo importante, tener cierta habilidad comunicativa (que creo no tengo) y ensayar la charla para ajustarla al tiempo del que se dispone y otras tantas cosas como estas. A pesar de que fue una charla de dos horas hay muchos detalles que se quedaron fuera, solo vimos la superficie de todo lo que tiene que ofrecer este framework.

En la charla surgió alguna pregunta interesante como ¿por que teniendo Tapestry ya más de 10 años de vida no es un framework más usado? Algunos de los motivos que dí fueron que Tapestry tiene una curva de aprendizaje mayor que otros frameworks ya que cambia el modelo de desarrollo de los frameworks basados en acciones a uno basado en componentes. El modelo basado en acciones lleva usándose desde Struts y es ampliamente usado en diversos frameworks. Struts fué uno de los frameworks más utilizados en su momento y por tanto usar otro framework basado en acciones en el que en muchos casos lo único que cambia en esencia es el lenguaje de programación, es más rápido y no require adquirir tanto conocimiento nuevo para usar uno que siga los mismos principios. Desde entonces han surgido nuevos frameworks Grails, Play!, Symfony, Django, ASP.NET MVC, Ruby on Rails, … como digo en esencia en todos ellos el principal cambio es el lenguaje de programación. Otro motivo puede ser que los desarrolladores de Tapestry no tienen detrás a una compañía que les apoya finaciandoles para promover su uso y evangelizar a tiempo completo, aunque de vez en cuando lo hacen, el proyecto está dentro de la fundación Apache y los desarrolladores viven de la consultoría o proyectos que realizan. A pesar de tener unas características muy notables (IMHO), que se superan en cada nueva versión siguiendo la tendencia de las aplicaciones e innovando, a veces una buena solución no tiene por que ser la que más éxito tenga o sea la más usada, ¿por que linux no es un sistema operativo más usado en el escritorio? Los motivos serán diferentes en este caso pero el resultado es que lo que unos consideran la mejor opción no no tiene por que ser la más ampliamente usada.

Otra pregunta interesante que surgió fue que parte de lo que comenté sobre Tapestry también puede realizarse con el framework en concreto con el que lo comparamos, Grails aunque podría ser otro. Sí, probablemente estructurando las cosas de cierta forma en Grails se puede conseguir algunas cosas parecidas como reutilización de controladores, acciones y elementos visuales comunes (en el mismo proyecto, página y diferentes proyectos) pero desde luego habría que buscar una solución propia y resolver algunos problemas que ya resuelve Tapestry por nosotros como generación de ids únicos para los elementos visuales (ids de las etiquetas) de forma que no haya conflictos, inclusión de recursos según los componentes de la página, internacionalización (i18n) de assets (imágenes, plantillas), sin lógica en las plantillas y siguiendo el modelo pull en las vistas, reutilización en diferentes proyectos con librerías, configuración distribuida para el contenedor de dependencias, detección de errores de compilación en las plantillas, página de excepción informativa y para peticiones ajax, actualización de zonas de una página con cero javascript, actualización de multiples zonas de una página en una única petición ajax, servicios mutuamente dependientes, instrumentación invisible en las plantillas, integración de RequireJS en el lado del servidor y cliente, eventos y comportamiento diferente según el elemento contenedor ante un mismo evento, escalabilidad …. Algunas serían posibles, otras quizá no y posiblemente en las posibles tendríamos que implementar nosotros alguna solución propia, no seguirían las indicaciones que se proporcionan en el manual de Grails y quizá las cosas no serían manejables ni quedarían de una forma que quedásemos a gusto con el código. A pesar de todo la herramienta utilizada no es lo más importante, pero si es cierto que utilizar una u otra si puede contribuir a hacer ciertas cosas más de forma más sencilla y cuando las cosas alcanzan un volumen grande sigan siendo manejables (no haya duplicación, no se produzcan muchos errores al hacer cambios, reutilización) que es cuando Tapestry en teoría empieza a mostrar sus virtudes. Lo mismo que se puede hacer con Grails o Tapestry también se puede hacer con servlets y JSP pero probablemente acabaríamos simulando un nuevo Grails o Tapestry, mejor usar el que más nos facilite las tareas y uno que probablemente será mejor que cualquier cosa que podamos hacer nosotros además de no tener que encargarnos de hacerla ni mantenerla. Grails también tienen algunas cosas destacables «built-in» que en Tapestry hay que proporcionarlas con alguna librería, como GORM. Si hay tantos frameworks, librerías, etc ahí fuera probablemente sea porque hay diferentes necesidades, puntos de vista diferentes de como resolverlos, … en definitiva es cuestión de elegir el que más nos convenza por diferentes motivos y la elección puede ser subjetiva.

Y otra pero no menos interesante pregunta es por que tapestry se llama tapestry o por que el logo de tapestry es un unicornio, anteriormente fue similar a una T en la versión 3, para el nombre no tengo respuesta. Leyendo un hilo en la lista de destribución en la que se discutía el asunto se da algunas ideas pero no me ha quedado una clara.

A continuación la presentación completa de la charla que dí y que contiene de forma más explícita todo lo que está incluido en el libro PlugIn Tapestry.

Un par de gracias, la sensación de haber aportado algo (o al menos haberlo intentado), el ruido que hicimos en twitter con el hastag #tapestry5, unos pocos seguidores adicionales y algunos retweets incluido el del principal hacedor de Tapestry fue suficiente recompensa.

Un blog desde hace ya 4 años, un libro el año pasado, una charla este ¿que será lo siguiente? «Non gogoa, han zangoa».