Migración de JSP a Facelets

1
46319

Migración de JSP a Facelets.

0. Índice de contenidos.

1. Introducción

En este tutorial vamos a analizar, paso a paso, cómo migrar una aplicación JEE, basada en el estandar JSF, de JSPs a Facelets.

Facelets es un framework ligero que permite el uso de plantillas en aplicaciones JSF. Se compara al sistema de plantillas de Apache Tiles que se usa con Apache Struts.

Las principales ventajas de Facelets son:

  • Construcción de interfaces basadas en plantillas,
  • Rápida creación de componentes por composición,
  • Fácil creación de funciones y librerías de componentes.

Si tienes alguna aplicación que mantener basada en JSF y construida en JSPs, espero que este tutorial te sirva para evaluar el coste de su migración a Facelets.

2. Configuración de facelets.

  • Añadimos la dependencia, en el descriptor del proyecto de Maven (en el pom.xml), a la última librería de faceletes:

     
       com.sun.facelets
       jsf-facelets
       1.1.14
     
    

    Si no tenemos Maven, incluiremos dicha librería en la carpeta WEB-INF/lib de nuestra aplicación web, la podemos descargar desde la home del proyecto facelets

  • Modificamos el prefijo de las páginas con componentes jsf, en el fichero de configuración web.xml:

    Antes:

    
       javax.faces.DEFAULT_SUFFIX
       .jsp
     
    

    Después:

    
       javax.faces.DEFAULT_SUFFIX
       .jspx
     
    

    Facelets requiere de páginas xhtml con una estructura xml bien formada y válida, la extensión jspx es por comodidad en el desarrollo para que el IDE autocomplete,
    podríamos usar igualmente la extensión xhtml.
    Cuando se pida al servidor una página jsf ya no buscará un recurso jsp, sino jspx o xhtml.

  • Podemos incluir los siguientes parámetros de contexto, en el fichero de configuración web.xml:

       
         facelets.REFRESH_PERIOD
         2
       
       
         facelets.DEVELOPMENT
         true
       
       
         facelets.SKIP_COMMENTS
         false
          
    
    • facelets.REFRESH_PERIOD: indica el intervalo en segundos para revisar si ha existido alguna modificación en los fuentes (xhtml o jspx), si un recurso ha sido modificado se cargará en caliente.
    • facelets.DEVELOPMENT: indica que estamos en el entorno de desarrollo, y frente a un error en el programa nos mostrará una página detallada con la información del mismo, así como una renderización del árbol de componentes jsf que tenemos en memoria.
    • facelets.SKIP_COMMENTS: por defecto elimina los comentarios xml del fuente de nuestras páginas xhtml o jspx.

    El parámetro que elimina los comentarios deberíamos invertirlo (ponerlo a true) y el resto los deberíamos comentar antes de la liberación de la release, puesto que sólo tienen sentido en desarrollo.

  • Redefinimos el gestor de las vistas en el fichero de configuración faces-config.xml:

     
       ...
       com.sun.facelets.FaceletViewHandler
       ...
     
    
  • Debemos modificar la extensión de los ficheros *.jsp por *.jspx en las reglas de navegación de JSF, en el fichero faces-config.xml o faces-navigation.xml

    Antes:

     	
    		Menu bar links
    		*
    	   ...
    		
    			inbox
    			/pages/inbox.jsp
    		
    		...
    	
    	
    		/pages/faq/list.jsp
    		
    			editContact
    			/pages/contact/edit.jsp
    		
    		...
    	
    

    Después:

     
    		Menu bar links
    		*
    	   ...
    		
    			inbox
    			/pages/inbox.jspx
    		
    		...
    	
    	
    		/pages/faq/list.jspx
    		
    			editContact
    			/pages/contact/edit.jspx
    		
    		...
    	
    

3. Soporte para facelets de librerías de componentes JSF.

Si tenemos librerías de componentes JSF propias, como es nuestro caso, por cada *.tld que tengamos creada, necesitamos dar de
alta una *taglib.xml para todos los componentes de la libería. La ubicación de los ficheros *taglib.xml es el directorio META-INF de la aplicación web.

El contenido del fichero taglib.xml viene a ser como sigue:

 
 
 
     http://www.autentia.com/client/project
     
         vacationCalendar
         
             com.autentia.client.jsf.HtmlVacationCalendar
             com.autentia.client.jsf.HtmlVacationCalendarRenderer
         
     
 
  • el contenido de la etiqueta namespace se corresponde con el nodo taglib/uri de la *.tld.
  • el contenido de la etiqueta tag-name se corresponde con el nodo taglib/tag/name de la *.tld
  • el contenido de la etiqueta component-type se corresponde con el nodo component/component-type del faces-config.xml
  • el contenido de la etiqueta renderer-type se corresponde con el nodo render-kit/renderer/renderer-type del faces-config.xml

Si estamos usando la librería de componentes Apache Tomahawk podemos añadir la siguiente dependencia en el pom.xml de nuestro proyecto:

  
     com.google.code.tomahawk
     tomahawk-facelets-taglib
     1.1.6.2
   

Esta librería no se encuentra en ningún repositorio público de Maven con lo que tendremos que añadirla al repositorio de Maven de nuestra organización. Para su descarga podéis acceder a la home del proyecto tomahawk-facelets

4. Modificaciones en los JPSs.

Todas las modificaciones vienen dadas por la necesidad de tener, en los fuentes de nuestras páginas (xhtml o jspx), un xml bien formado y válido. Son las siguientes:

  • Modificación de la extensión de todas las páginas *.jsp a *.jspx.
  • Eliminación de las importaciones de tag lib como &lt@ taglib, ahora son espacios de nombres en el nodo raíz de la página (xmlns:h=»…»)

    Antes:

      <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
      <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
    

    Después:

      
    
  • los <@include file=»…» /> deben ser <ui:include src=»/wp-content/uploads/tutorial-data/…» />
  • los scriptles <% %> deben suprimirse,
  • los comentarios en scriptles <%– –%> tienen que ser comentarios en xml <!– –>
  • el acceso al contexto de facletes vía scriptlet <%=facesContext… debe hacerse vía Expression Language #{facesContext…}
  • todas las entidades xml deben cambiarse a su formato numérico: los &nbsp; ahora son  
  • si tenemos algún atributo duplicado en la definición del nodo raíz de alguna etiqueta que renderiza un componente JSF (p.e., dos styleClass en un mismo <h:panelGroup…),
    ahora se producirá una excepción de atributo duplicado,
  • el componente <f:verbatim no puede tener otros componentes jsf en su interior, si es así no se renderiza
  •     
        
    
  • dentro de un atributo de un componente no se pueden incluir llamadas a funciones de jstl:
        
        
    

    Se debe usar:

        
        ...
        
    
  • Si tenemos alguna expresión con un & hay que escaparla a &amp; o sustituirla por un and:
  •      
         
         
    

5. Implementación de un sistema de plantillas.

Ya hemos visto en adictos al trabajo cómo crear un sistema de plantillas con facelets, me remito al manual de Alejandro para su creación.

Una vez tenemos creado el layout básico de nuestra aplicación y lo hemos incluido en una plantilla de facelets, bastaría con recorrerse una a una las páginas jspx para asilar su contenido individual y encapsularlo dentro una llamada a la plantilla.

  
  
  
    
    	    
    	
    		Listado de libros
    		
    		  
    			
    			 
    			 ...
    			 
    			
    		
    	
    	
    
  			

El trabajo consistirá el eliminar todo el código que sea común y ya esté en la plantilla y, aquél individual a la página, incluirlo en la definición de una variable.

Si teníamos un <@include en todas las páginas JSP ahora solo lo necesitamos en la plantilla como un <ui:include.

6. Conclusiones.

Los beneficios de tener un sistema de plantillas como facelets son evidentes, en la migración sólo se modifica la presentación
y aunque las modificaciones son transparentes para el usuario final, la aplicación gana bastante mantenibilidad.

También aumenta en rendimiento, puesto que ahora las páginas que «pintan» las vistas ya no son JPSs,
con lo que ya no se compilan, ni se genera un servlet por cada una de ellas. Facelets lee el árbol de componentes de la página jspx una sola vez.
El aumento en el rendimiento de la aplicación sí es perceptible por el usuario final.

El coste de la migración es perfectamente asumible, para que tengáis una referencia: una aplicación con 120 páginas jsp se ha migrado en 3 jornadas por
una sola persona, incluido el coste de investigar la mejor manera de llevarlo a cabo, la documentación de la migración (este tutorial) y las pruebas.
Sí es cierto que nosotros tenemos las aplicaciones muy normalizadas y nuestros fuentes son todos muy estandar,
con lo que podemos hacer modificaciones masivas en el código sin miedo.

Si os animáis, contadnos qué tal os ha ido! y si no, pensad que siempre lo podemos hacer nosotros!!!, trabajamos en esto.

Un saludo.

Jose

1 COMENTARIO

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad