style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

Tapestry 5.2 stable liberado

Me es muy grato informar que por fin después de una larga espera de 8 meses sale a la luz la versión estable de Tapestry 5.2

Entre las características más sobresalientes son que ya no se utiliza un pool de páginas lo cual mejora increiblemente el rendimiento de las aplicaciones que utilizan cientos de componentes.
Live Service reloading que permite hacer cambios a los servicios y con solo dar f5 en el navegador estamos viendo el cambio (igual a como sucede con las páginas/componentes/mixins), mejoró el testing de páginas y componentes, mejoró la documentación, se tiene un nuevo sitio, entre múltiples bugs corregidos.

Aquí todas nuevas características a detalle:
http://tapestryjava.blogspot.com/2010/12/announcing-tapestry-52.html

¿Qué esperas para probarlo?

Comentarios

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

jm2.0

ya le subí la versión a javaMexico 2.0 para que use 5.2.4.

Me parece algo curioso que eso del pool de páginas es algo que cacareaban mucho desde la versión 3.0 precisamente porque mejoraba mucho el desempeño de las aplicaciones en cuanto a velocidad y uso de memoria, y ahora resulta que lo quitan por las mismas razones...

Imagen de iberck

Pool de páginas

Inicialmente el pool de páginas lo crearon para poder utilizar variables de instancia dentro de los componentes/páginas y evitar problemas de concurrencia como sucede con los servlets.
A muy grandes rasgos cada que un usuario pide una página/componente, Tapestry saca del pool una instancia, el cliente hace uso de ella y al final vuelve a meter dicha instancia con sus valores reseteados para cuando la pida otro thread esté limpia.

Ahora, el nuevo esquema ya no utiliza un pool de páginas pero SE PUEDEN SEGUIR MANEJANDO VARIABLES DE INSTANCIA SIN PROBLEMAS DE CONCURRENCIA, el truco está en que Tapestry va guardando los valores de cada thread en un mapa, con esto se evitan cientos de operaciones/validaciones y mejora considerablemente el rendimiento en aplicaciones grandes.

Imagen de ezamudio

ConcurrentHashMap

Y se me hace que la razón de todo este cambio fue que en T5 ya usan el ConcurrentHashMap que llegó en Java 5...

Imagen de iberck

No lo sé, pero si de algo

No lo sé, pero si de algo estoy seguro es que se están poniendo las pilas con un buen líder a la cabeza y este framework me gusta cada día más :)
Desde que reestructuraron su página se ve la documentación mucho más ordenada, con más estructura, más elaborada.... más bonita: http://tapestry.apache.org/

Por cierto, has visto el nuevo logo no-oficial de tapestry?

Mejor representado no podría estar ;)

Imagen de ezamudio

jajajajaj

está buenísimo jajajaja. Lo que no sé es por qué es un unicornio; en la versión 3 creo que era como una T medio rara y ya.

Ahí a ver si le echas un ojo a lo que llevamos de javaMexico 2.0.

Imagen de iberck

Invitación miembros Tapestry

Si, creo que la T la utlizaban en T3.0 y luego cambiaron al unicornio verde, sin embargo este ferrari se lleva las fanfarrias :)

En cuanto al proyecto si, me daré un tiempo y "que tal si si !!!" publicaré una invitación en el foro de tapestry haber si algún hispano quiere unirse y digo hispano porque la intención es codificar y documentar en español porque lo importante es que los miembros hispanos del sitio aprendan de este proyecto.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">