Tapestry 5.2.1 Beta Release Disponible

Me complace anunciar el lanzamiento de la última versión de Tapestry, esta versión es beta pero como algunos saben tapestry tiene versiones beta muy estables.

Entre las mejoras más sobresalientes:

  • Ya no se utiliza un pool de páginas, en lugar de ello se guardan las variables de cada thread de manera independiente, lo cual hace que mejore considerablemente el performance en aplicaciones muy grandes
  • Mejoras a Live class reloading, ahora no solo funciona con las páginas y componentes, también funciona con los servicios!
  • JSR-303 Bean Validation Integration
  • Una nueva anotación para contribuir los métodos @Contribute
  • 2 nuevas anotaciones que son muy útiles para el manejo de parámetros @RequestParameter,@ActivationRequestParameter
  • Actualizadas las librerías de tapestry-spring, ahora depende de spring3
  • Actualizadas las librerías de tapestry-hibernate, ahora depende de Hibernate 3.5.4
  • Se agregaron zonas a los selects (ya se esperaba este cambio)
  • Corregidos múltiples bugs
  • Algo que también se esperaba es que mejoren la documentación y se están poniendo las pilas, han sacado este nuevo sitio en donde se espera documenten más casos de uso

Las cosas que esperaba pero siguen si salir:

  • Los fanáticos de jquery tendremos que esperar una integración hasta Tapestry 5.3
  • Hace falta un liveclass reloading completo
  • Se espera que en la versión Final 5.2 ya esté muerto javaassist, en este momento lo quieren reemplazar con asm

Bueno, pues a probarla porque está como pan caliente

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

JSR303

Eso es probablemente el mejor cambio, sobre todo si usas Hibernate. Ahora ya puedes meter JSR303 estándar en tus clases de dominio y esas validaciones las puede interpretar tanto Hibernate a la hora de salvar, como Tapestry en los BeanEditorForm.

No sé cuál sea la decisión de fondo para desechar javassist pero seguramente lo han usado bastante y sus problemas tendrá, para que prefieran pasarse a asm.

Imagen de iberck

Razones para sacar Javaassist de Tapestry

Una de las razones por las cuales quieren sacar javaassist de tapestry 5 es porque después transformar las clases, genera muchas cosas tras bambalinas y parece que con asm se tendría un mejor rendimiento, otra razón por la cual quieren hacerlo es para evitar las  
Entrando un poco en la madriguera, estas son algunas de las razones por las cuales se ha tomado la decisión:
Aquí habla un poco sobre la generación del byte code en tapestry y de la arquitectura con javaassist:

Una TransformationException se presenta cuando javaassist no puede transformar correctamente tu código fuente, muchos piensan que este tipo de excepciones son culpa de Tapestry por hacer mal uso de las convenciones (por ejemplo no definir las variables con el atributo private), sin embargo esto es un problema ageno a tapestry y lo ha heredado de javaassist.
Aquí tienes una pequeña probadita de este tipo de excepciones:
En ese preciso post Howard Lewis indica que las TransformationExceptions son un problema de Javaassist y que es una de las razones por las cuales lo quieren sacar del framework. El tercer thread de ese mismo post habla sobre las supuestas "mañas o precauciones" que debemos tener al momento de programar para evitarlas


Co-workers told me that they used to follow certain
"code conventions" that prevented Javassist to write wrong transformations
(eg. using getter/setter instead of direct property access, don't put a lot
of code inside onActivate() - put the logic on a private method and call the
method inside onActivate()).

Personalmente me ha sucedido que cuando inyecto una página dentro de otra página y hago uso de sus atributos, "a veces" me lanza una TransformationException en tomcat, también me ha lanzado este tipo de excepción cuando el código fuente del método setupRender es muy largo, o simplemente porque sí y en cualquier lugar y desconozco exactamente cuál y porqué es el bug en la librería.
Para encontrar este tipo de excepciones tienes que ir buscando línea por línea en todo tu código fuente del componente o la página hasta encontrar la línea exacta que no puede ser transformada por javaassist.

Algunos recomiendan compilar con una versión distinta de jdk, hacer un update o incluso un downgrade de javaassist
La manera de parchar este tipo de errores puede ir de lo sublime a lo ridículo, me ha tocado que para parchar una mala transformacion he tenido que envolver una variable en un   o incluso he tenido que repetir líneas de código fuente para engañar a javaassist. Tan solo leer lo que yo mismo estoy escribiendo hace que los pelos se me pongan de punta ya que estos errores son invisibles en jetty, pero a la hora de montar a producción y cambiar el servidor de aplicaciones es cuando empiezas a sudar frío, haciendo semejanza a microedition pareciera que jetty es el emulador y que montar la aplicación a producción fuera como probarlo en un dispositivo real. Una vez me sucedió que subí una aplicación a producción y no probé darle click a un botón ya en tomcat, "afortunadamente" me dio una   y digo afortunadamente porque el miedo de haber visto eso en producción me impulsó a investigar sobre el tema.
Ojo, esto no se trata de un problema con tapestry-tomcat, se trata de un problema de javaassist mezclado con algo desconocido y obscuro para mí, yo simplemente hablo de lo que a mí me ha sucedido y cómo lo he resuelto, tal vez jetty no tiene el ingrediente que hace que javaassist se haga ácido.
Tampoco quiero que todo este post esté repleto de patadas hacia javaassist porque gracias a dicha librería es que Tapestry tiene la magia debajo de la manga, el cambio se hará para tener una pequeña mejora de rendimiento en el API que transforma las clases al vuelo.

En fin, este comentario no es para espantar a la gente nueva que está aprendiendo o migrando a Tapestry 5 o para generar incertidumbre, los problemas de TransformationException que estoy comentando aquí son parte del pasado (de la versión 5.0.18 para abajo) y es como una advertencia para actualizar a la versión 5.1.0.15 o superior, o para la gente que aún utiliza la línea 5.0.x sepa más o menos por dónde tirarle.
Con la última versión estable no hay mucho de qué preocuparse ya que viene actualizada con la última versión la librería javaassist, quienes han parchado muchos bugs importantes que generan este tipo de excepciones.
En resumen, si tienen la última versión de Tapestry no hay de qué preocuparse, el framework es muy estable, además siguen los planes de dejar la librería fuera de la jugada pero más por razones de rendimiento que por otra cosa:

Veo que el proyecto javamexico2.0 está siendo realizado con Tapestry 5 y si no lo han actualizado a la última versión estable les recomiendo que lo hagan ya.
Personalmente creo que ha sido la mejor decisión tomar este framework y tienen mi voto de confianza porque con Tapestry tienes muchas cosas, entre ellas una programación bastante rápida, sencilla, reutilizable (basada en componentes), escalable, entre muchas otras.

Muchos creen que es dificil aprender Tapestry porque su curva de aprendizaje es alta pero no es así, vamos, es como tener un mal hábito, te sientes cómodo con lo que tienes (tal vez un framework donde pareces obrero porque trabajas mucho y ves poco) y no quieres cambiar aunque sea para bien porque piensas que es difícil e implica cambiar la forma de hacer las cosas y de pensar. Pero desde aquí te digo que no es difícil y vale mucho la pena entrarle a Tapestry, simplemente se trata de cambiar a la manera correcta de hacer las cosas y tienes muchos, muchos, muchos beneficios entre ellos la agilidad y la intuición que ganas al desarrollar y así como te hablo desde mi trinchera de este antiguo problema, también te puedo decir desde mis lentes que es el mejor framework web que he visto para programar con java.

En cuanto a las nuevas características a mi me parece impresionante que hayan sacado el pool de páginas y ahora sólo se utilice una sola instancia de cada clase, igualito a como lo hacen los servlets pero con la ventaja de que no tienes que preocuparte por la sincronización de threads porque Tapestry internamente guarda las variables de cada uno en un mapa para hacerlas independientes. El proceso es totalmente transparente y no es necesario cambiar una sola línea de tu código fuente. Aquí se habla un poco del tema: y aquí la lista completa de todos los cambios en Tapestry 5.2

Bueno, creo que ya está muy largo el choro...

Te mando un saludo

Imagen de benek

jQuery

Don iberck,

¿Aquello de que para 5.3 pondrán jQuery es solamente algo que deseas o realmente están pensando en ello?

Sería fabuloso tener jQuery a la mano en Tapestry.

Saludos.

Imagen de iberck

JQuery

De hecho puedes tener jquery en tapestry pero no es una librería oficial, existe un módulo para sacar por completo prototype y añadir el stack de jquery.
Se espera que para la versión 5.3 lo hagan de manera oficial y se pueda integrar yui,jquery,prototype,dojo o lo que se te ocurra porque van a dividir por stacks de JS--
De hecho ya se empieza a ver movimiento en los repositorios...

Imagen de VictorManuel

JQuery

Sabes como pa cuando una estimacion de la salida del 5.3??

Imagen de iberck

tapestry5-jquery

Los releases son aprox de 6 a 8 meses

Pero si lo que quieres es tener tapestry con soporte de jquery desde sus entrañas, existe este proyecto:

Lo que se espera para la versión 5.3 es una separación por stacks de frameworks javascript

Imagen de ezamudio

iberck

Estimado iberck, pues a ver si le puedes echar un ojo rápido a la aplicación de JavaMexico para que no tengamos problemas de los que ya conoces y que luego nos vaya a dar la sorpresa de que no jala en tomcat/jboss/whatever... porque en pruebas con jetty no ha tenido broncas pero pues por lo que mencionas, prefiero evitarnos los tropezones desde ahorita...

Imagen de iberck

Arquitectura JM2.0

Hola, ya revisé la aplicación y están correctas las librerías de tapestry, con esas configuraciones yo no he tenido ningún problema a la hora de montar a otro container
Dónde podemos abrir un hilo para discutir algunas cosas de la arquitectura?

Imagen de ezamudio

abre uno en jm2

segun yo ya hay una sección de JavaMexico 2.0 en los foros...

Imagen de iberck

Ok, entonces vamonos de

Ok, entonces vamonos de aquí...