Tapestry frente a JSF

Convención frente a configuración. Apache Tapestry como alternativa a JSF

0. Índice de contenidos.

• 1. Introducción
• 2. Entorno
• 3. Primeras diferencias entre Tapestry 5.1 y Jsf 2
• 4. Unas pinceladas de Tapestry 5.1
• 5. Conclusiones
• 6. Información sobre el autor

1. Introducción

En estos días me estoy sumergiendo algo más en el mundo de Tapestry, y en este artículo voy a tratar de explicar las ventajas e incovenientes que me he ido encontrando, así como las cosas que me gustan y las que no me gustan tanto.

Para el tutorial me voy a basar en la documentación oficial de Tapestry y en el tutorial que nos vale de iniciación.

2. Entorno

• Hardware: Portátil MacBook Pro 15′ (2.0 GHz Intel i7, 8GB DDR3 SDRAM, 500GB HDD).
• AMD Radeon HD 6490M 256 MB
• Sistema Operativo: Mac OS X Snow Leopard 10.6.7
• Software relacionado con el tutorial: Eclipse Helios, Tapestry 5.1.0.5 y Jetty 6.1

3. Primeras diferencias entre Tapestry 5.1 y Jsf 2

Lo que más me ha llamado la atención es la forma que tienen cada uno de atender las peticiones. Mientras que en Jsf existe un @ManagedBean instanciado en modo Singleton sin estado que atiende todas las peticiones con el ciclo de vida propio de Jsf, en Tapestry tenemos un pool de páginas que funciona a groso modo según el siguiente ciclo de vida:

• 1. Llega una petición al servidor.
• 2. Se comprueba qué página se está solicitando y se carga instanciando todos sus componentes.
• 3. Una vez cargada la página esta se vincula a la request (petición) actual.
• 4. Cuando se termina la petición y la respuesta se ha enviado al cliente la página se separa de la petición, se liberan los objetos java ligados a ella para que el garbage collector pueda liberar
  esa memoria y se mete en el pool de páginas, marcando su estado a disponible para que otra petición pueda usarla.

El pool de páginas es un mecanismo curioso. Vamos a ver algunas de las propiedades que podemos usar para configurarlo y así poder entender mejor su funcionamiento.

tapestry.page-pool.hard-limit es el número total de peticiones que Tapestry va a atender. Si llegan más peticiones directamente serán rechazadas. Como por petición se utiliza una página podemos entender también este número como el máximo de páginas que vamos a tener en el pool. También va a indicar el número máximo de páginas activas. Una página esta activa cuando esta ligada a una resquest.

tapestry.page-pool.soft-limit nos indica el número de páginas a partir de las cuales el sistema empezará a esperar por si se nos devuelve una página que haya quedado libre en el pool. Este tiempo se puede configurar mediante la propiedad tapestry.page-pool.soft-wait. Por defecto son 10 ms.

Estas propiedades nos sirven para profundizar un poco más en el funcionamiento del pool de páginas que sería el siguiente:

• 1. Llega una petición solicitando una página a la aplicación.
• 2. Se comprueba si en el pool hay ya alguna instancia de esa página. Este punto es bastante importante ya que una vez cargada una página, Tapestry la mantiene en el pool durante cierto tiempo que varia en función de las peticiones siguientes y de las propiedades que hemos visto antes, por lo que cuando se requiere esta página por segunda vez o sucesivas, esta se servirá mucho más rápido que cuando se pidió por vez primera, ya que se tiene que instanciar la página y todos los componentes de los que se componga. Es un buen consejo por lo tanto, una vez despleguemos una aplicación que use Tapestry navegar por las distintas páginas para que estas se instancien, mejorando la experiencia de los usuarios que soliciten páginas después, al reducir el tiempo de respuesta.
• 3. Si el pool no tiene una página disponible del tipo que solicita la petición pueden ocurrir 2 cosas. La primera es que estemos por debajo de tapestry.page-pool.soft-limit en cuyo caso directamente se instanciaria una página de ese tipo. Si estamos por encima esperaríamos tanto tiempo como se indique en tapestry.page-pool.soft-wait. Si después de esperar, el pool tiene una página disponible del tipo que solicita la request utilizaremos esa, y solo habremos esperado tapestry.page-pool.soft-wait tiempo. Por el contrario si no hay una página disponible se creara una nueva, con el consiguiente gasto de tiempo en hacerlo.

Si hemos entendido bien la parte anterior vemos que lo ideal es que tapestry.page-pool.soft-wait sea menor que el tiempo que tarda en crearse una nueva instancia de página, ya que si tardáramos más en esperar que en crear una nueva, estaremos penalizando el tiempo de respuesta. Por lo dicho anteriormente no parece una buena idea poner un valor alto a dicha propiedad.

4. Unas pinceladas de Tapestry 5.1

Si venimos de JSF, adaptarse a Tapestry puede llevar un tiempo. Para empezar, en la vista tenemos algunos «operadores» como <t:if> y <p:else> que podemos usar para pintar o no capas o componentes en función del atributo test de <t:if>, por ejemplo:

  
      
    
  
          
        
                         
              
        
  
    
  
      
  
  
    
${message:user.notActive}
    
  
   
      
 

En esta pequeña porción de vista hay bastantes cosas diferentes respecto a JSF:

• En la línea 1 estamos indicando que en el controlador de esta clase que por convención se llamará igual que la vista, pero acabado en .java, y no en .tml ( que es la extensión para las vistas ), tendrá un método llamado userInformationInfoRendered que nos devolverá un booleano. Este booleano determinará si se renderiza la parte que está debajo del <t:if> o la parte del <p:else>.
• En la línea 4 estamos indicando un label, pero no vemos por ningún lado el value. Esto es fruto de la convención de nuevo, para encontrar el valor lo que hace Tapestry es buscar en el fichero de propiedades el tag userName.
• En la línea 6 estamos referenciando al objeto user, que se debe encontrar en el controlador.
• En la línea 12 vemos como se usan los mensajes en Tapestry, mediante el uso de message, otra convención.

5. Conclusiones

Personalmente este framework me ha parecido que puede incrementar la velocidad de desarrollo usado correctamente, y cuando se tiene un conocimiento medio-avanzado de lo que se está haciendo. Hay cosas que no me han gustado nada, entre ellas lo siguiente:

• El hecho de tener que utilizar anotaciones como @Nonvisual en los atributos de las entidades cuando no quiero que la vista los represente. Esto no me gusta porque no creo que una entidad tenga que saber si se va a pintar uno de sus atributos o no.
• Cuando en base a la selección de un combo quieres cambiar otro, o ocultarlo, no hay una forma sencilla de hacerlo. Al menos yo no he encontrado lo que en JSF sería un update que refrescara parte de la vista. Me he visto forzado a hacerlo con Javascript.

En general implementar cosas nuevas que se salgan de la conveción, como en el caso anterior, no es sencillo, o al menos a mi no me lo ha parecido, por lo que a groso modo si tuviera que elegir entre convención y configuración, me quedo con configuración y con JSF, ya que me da más margen de maniobra. Pero esta es solo mi opinión.

6. Información sobre el autor

Alberto Barranco Ramón es Ingeniero Técnico en Informática de Gestión y Graduado en Ingeniería del Software por la Universidad Politécnica de Madrid

Mail: abarranco@autentia.com.

Twitter: @barrancoalberto

Autentia Real Business Solutions S.L. – «Soporte a Desarrollo».