Libro sobre desarrollo de aplicaciones con Apache Tapestry

Recientemente he publicado PlugIn Tapestry, un libro acerca del desarrollo de aplicaciones web en el lenguaje Java y con el framework Apache Tapestry.

Apache Tapestry es un framework orientado a componentes para crear aplicaciones web rápidas, dinámicas, robustas y altamente escalables en la plataforma Java. Al basarse en componentes es distinto de los muchos basados en acciones similares en esencia a Struts que podemos encontrar en la plataforma Java como SpringMVC, Grails y Play! y también de los muchos otros en los que la principal diferencia es el lenguaje como Django (Python), Symfony (PHP), .NET MVC (C#) o Ruby On Rails (Ruby).

Incluyendo la descripción de las características del framework el libro trata la mayoría de aspectos que puede necesitar una aplicación o página web, entre ellos:

• Introducción, principios y características
• Inicio rápido
• Páginas y componentes
• Contenedor de dependencias (IoC)
• Assets (imágenes, estilos, javascript) y módulos RequireJS
• Formularios
• Internacionalización (i18n) y localización (l10n)
• Persistencia web
• Persistencia en bases de datos
• Ajax
• Seguridad (autenticación, autorización, XSS, Inyección SQL)
• Librerías de componentes
• Pruebas unitarias, de integración y funcionales (JUnit/Mockito, Spock, Geb)
• Y algunas cosas más

El libro está basado en la siguiente versión de Tapestry, la 5.4, que actualmente está en estado alpha (aunque la mayoría servirá para la versión final y para la versión 5.3 actual). Esta versión tiene como principal novedad la parte cliente de las aplicaciones con la inclusión de RequireJS y la definición de los archivos Javascript mediante módulos. También incorpora una capa de abstracción que permite usar cualquier librería como apoyo a la funcionalidad que necesita proporcionar ya sea Prototype, jQuery, cualquier otra que prefiramos o nueva que se desarrolle en un futuro.

Además del libro he desarrollado una pequeña aplicación (disponible en mi repositorio de GitHub) con unos pocos ejemplos que puedes probar en tu equipo sin necesidad de instalar nada previamente, salvo Git y el JDK. Más de 200 páginas de documentación que permitirán al lector descubrir mucha de la magia que puede ofrecer este framework. Además en mi blog puedes encontrar varias entradas sobre muchos de los temas tratados de forma individual y que he utilizado para escribir el libro.

Puedes descargarlo desde la página que he preparado para ello de forma totalmente libre y al inmejorable precio de 0,00€ impuestos incluidos. Tienes mi permiso (es más, animo a ello) para compartirlo, distribuirlo en redes P2P, subirlo a cualquier página web o «piratearlo» cuantas veces quieras, siempre que respetes la licencia Creative Commons bajo la cual lo he publicado.

Algunas características destacadas de Apache Tapestry son:

Java
Normalmente se usa el lenguaje Java con lo que el compilador y el asistente de código de tu IDE te ayudarán.

Políglota
Si prefieres puedes utilizar Groovy, Scala o cualquier otro lenguaje soportado por la JVM.

Productivo
La recarga de clases en caliente evitará que tengas que reiniciar el servidor para ver tus cambios aplicados. Simplemente actualiza el navegador.

Rápido
El framework está programado en Java sin hacer uso de reflection. Incorpora varias optimizaciones que harán tu aplicación más eficiente sin trabajo por tu parte como compresión gzip, minificación y agregación css/javascript, cacheo agresivo en el cliente de assets, supresión de espacios en blanco innecesarios, ...

Basado en componentes
Los componentes son piezas autónomas y resusables de código. Para usar uno simplemente necesitarás conocer sus parámetros todo lo demás como archivos javascript, hojas de estilo y mensajes localizados son proporcionados por el componente. Los componentes pueden lanzar eventos y diferentes contenedores comportarse de diferente forma ante el mismo evento.

Informe de error avanzado
El informe te proporciona mucha más información que simplemente la traza de la excepción, verás que se estaba haciendo, que fué mal y como coregirlo. Con toda esta información solucionar las excepciones será mucho más rápido y fácil. El informe de error también es presentado en caso de errores en las peticiones AJAX.

Testable
Puedes probar los componentes de forma unitaria, el html generado o hacer pruebas de integración y funcionales. Los componentes son POJOs que no necesitan heredar ni implementar ninguna clase del framework. Podrás utilizar la herramienta que desees JUnit/Mockito, Spock, Geb, ...

Extensible, adaptable y modular
Gracias al contenedor de dependencias y a que los servicios están programados en base a interfaces puedes definir una nueva implemetación que modifique el comportamiento del framework. Todo servicio en el contenedor de dependencias puede ser redefinido, la mayoría de las cosas son servicios. Exiten módulos para Hibernate, Apache Shiro, Quartz, ... y si no existe puedes usar cualquier librería como RESTEasy, JasperReports, EHCache, JFreeChart, RestFB...

i18N y l10N
Puedes tener catálogos de mensajes por componente o de manera global en la aplicación. Los assets (imágenes, css, ...) tanbién son localizables y tener una plantilla con un contenido totalmente diferente según el idioma del usuario.

Convención sobre configuración
Las convenciones permiten evitar la configuración y los posibles errores que podemos cometer al realizarla. Pero más importante, hace que cualquier programador que conozca las convenciones sepa inmediatamente como están organizadas todas las cosas con lo que el tiempo de aprendizaje se reduce considerablemente.

Librerías de componentes
Los componentes comunes a varios proyectos pueden ser agregados en una librería de componentes (no es más que un archivo jar) para ser reutilizados. Nuevamente para usar los componentes solo tendrás que preocuparte de los parámetros, todos los recursos que necesiten serán extraídos de la librería. No necesitarás copiar y pegar archivos de un proyecto a otro, solo agregar una dependencia o jar a tu proyecto.

Según su principal desarrollador (Howard Lewis Ship, que obtuvo el premio Java Champion en 2010 [1] y Duke's Choice Award por el framework [2] en la categoría open source), y modestia aparte, piensa que Tapestry ha sido un líder desde una perspectiva puramente tecnológica. Estas son algunas cosas que cree que hizo primero y todavía piensa que lo hace mejor que nadie:

• Componentes reusables (2001)
• Informe de excepción detallado y útil (2001)
• Instrumentación invisible en las plantillas (2002)
• Informe de error con precisión de linea (2004)
• Metaprogramación y modificación de bytecode (2005)
• Recarga de clases en caliente (2006)
• Informe de error completo para peticiones Ajax (2012)

¿Te ha parecido poco? ¡Descubre más en el libro!. Que lo disfrutéis, usar el siguiente enlace para ¡descargarlo!

Referencia:
Documentación sobre Apache Tapestry

[1] https://java.net/website/java-champions/bios.html#Ship
[2] https://www.java.net/dukeschoice/2006

DAO genérico para JPA (ORM)

Si usamos un ORM (Object-Relational Mapping) para la capa de persistencia en una base de datos relacional de nuestra aplicación ya sea Hibernate o JPA probablemente después de desarrollar unos cuantos servicios DAO nos daremos cuenta que tenemos unas cuantas operaciones básicas muy similares en todos.

Si queremos evitar tener duplicado ese código y ahorrarnos la codificación de esas operaciones básicas podemos desarrollar un DAO genérico que nos sirva para todas las entidades persistentes de nuestra aplicación usando los generics del lenguaje Java. Las operaciones candidatas a incluir en este DAO son: búsqueda por id, persistencia de un objeto, borrado, actualización, búsqueda paginada de todos los objetos y número de entidades persistidas de un tipo.

El código que podemos usar puede ser el siguiente:

Por supuesto, este DAO es muy simple pero podría ser ampliado para permitir hacer búsquedas además de sobre todos los elementos de una tabla y con paginación con unos determinados criterios de búsqueda que nos cubran las mayoría de los casos que necesitemos, es decir, podríamos implementar un método tal que le pasemos un objeto que se encargue construir lo que serían las cláusulas específicas de la consulta: findByCriteria(SimpleCriteriaBuilder criteria, Pagination pagination), findByNamedQuery(String namedQuery) o findByQuery(String query).

Referencia:
Código fuente completo del ejemplo
Persistencia con JPA y Apache Tapestry

Personalizar la página de informe de error en Apache Tapestry

Si en otra entrada explicaba como redefinir las páginas de los códigos de error HTTP en Apache Tapestry para personalizarlas y que tuviesen el mismo estilo que las páginas del resto de la aplicación. En esta entrada explicaré como redefinir la página de informe de error que se muestra cuando se produce una excepción y no es controlada.

En Tapestry se distingue entre la página de código de error HTTP 500 y la página del informe de excepción, aunque esta último también devuelve un código de error 500 se trata de otra página diferente. Esta página de informe de error también se muestra cuando se produce una excepción en una petición Ajax pero dentro de una ventana emergente dentro de la propia página.

La página de informe de error tienen el siguiente aspecto por defecto.

Como este aspecto no estará acorde con el resto de las páginas de la aplicación deberemos personalizarla. Creando una página personalizada de informe de error podemos darle el aspecto que al resto de páginas de la aplicación posiblemente usando el mismo componente Layout en todas.

Como se puede ver Tapestry proporciona mucha de la información que dispone acerca de la petición que nos servirá para corregirla de forma más rápida. Esta es una muy buena característica que posee Tapestry desde el año 2001, en otros frameworks habitualmente cuando se produce una excepción solo se te informa con la pila de llamadas de la excepción o excepcion strack trace que a veces no es suficiente para poder reproducir el problema. Por ejemplo, en Tapestry dispondremos de los parámetros que se enviaron en la petición y si la excepción se produce por ciertos valores o una combinación de ellos podremos reproducir el problema mucho más rápidamente que con solo la pila de llamadas de la excepción. Adicionalmente dispondremos de cierta información acerca del entorno en el que se está ejecutando la aplicación que a veces también nos puede ayudar a detectar el problema.

Para personalizar estas página deberemos crear en nuestra aplicación una página de nombre ExceptionReport, con esto será suficiente para que se muestre en vez de la de Tapestry por defecto. En ella distinguiremos entre el modo de desarrollo y producción, en el modo producción no mostraremos todos los detalles de la petición para no dar información interna de la aplicación al usuario.

Referencia:
Código fuente completo del ejemplo
Documentación sobre Apache Tapestry

Personalizar las páginas de error (404, 500, ...) en Apache Tapestry

Al desarrollar una aplicación y sobre todo si se trata de una página web pública a la que puede acceder cualquier usuario de internet es casi obligatorio hacer que las páginas de los diferentes códigos de error HTTP tenga el mismo estilo que el resto de las páginas de la aplicación y con el contenido que queramos indicar al usuario para que sepa porque se ha producido ese error y que puede hacer.

En Tapestry se puede redefinir la página de cualquier error HTTP, los más habituales son la del código de error 404 que es la de una página no encontrada o la del código de error 500 que es la página que se mostrará cuando se haya producido un error en el servidor.

Lo que hay que añadir para tener estas páginas personalizadas es un poco de xml en el archivo descriptor de la aplicación web (web.xml) y crear las propias páginas con el contenido que deseemos.

El código xml que debemos añadir es el siguiente:


En él indicamos que el filtro de Tapestry se encargue también de gestionar las páginas de los códigos de error y más tarde indicamos cuales son sus URL.

Una vez modificado el archivo web.xml deberemos crear las páginas personalidazas, no es diferente de cualquier otra página pero algo que nos puede interesar es distinguir si estamos en el modo producción o en el modo desarrollo para sacar más o menos información. En desarrollo nos puede ser útil disponer de esa información adicional. El símbolo SymbolConstants.PRODUCTION_MODE nos indica si estamos en modo producción y lo podemos configurar de diferentes formas, una de ellas es como un a contribución en el módulo de la aplicación.


La página de cualquier otro código de error HTTP sería similar a esta. Si quisiéramos mostrar una página de un código de error en la lógica de un componente debemos devolver en el manejador de evento un objeto HttpError:


Esta es una captura de pantalla de la página 404 con la aplicación en modo desarrollo.

Para finalizar la página de error 500 en Tapestry es diferente de la página cuando se produce una excepción en el servidor. Cuando se produce un excepción y no se controla de alguna forma Tapestry muestra la página ExceptionReport que explicaré como personalizar en otra entrada y que no es diferente de lo visto aquí.

Como en el resto de entradas el código fuente completo lo puedes encontrar en mi repositorio de GitHub. Si quieres probarlo en tu equipo lo puedes hacer de forma muy sencilla con los siguientes comandos y sin instalar nada previamente (salvo java y git). Si no dispones de git para clonar mi repositorio de GitHub puedes obtener el código fuente del repositorio en un archivo zip con el anterior enlace.


Referencia:
Documentación sobre Apache Tapestry