JSF y comparativa con Struts

2
68281

JSF – Java Server Faces (y comparación con Struts)

Creación: 15-08-2005

Índice de contenidos

  1. Introducción

2. Entorno

3. Instalación de MyFaces

4. Vamos al lío

4.1 customize.jsp

4.2 same-color.jsp

4.3 show-preview.jsp

4.4 Ficheros de recursos

4.5 ResumeBean.java

4.6 faces-config.xml

5. Internacionalización (i18n)

6. Recuperando los valores del formulario

7. Validación de los campos de entrada

7.1 Especificar las validaciones

7.2 Mostrar los errores de la validación

8. Gestión de eventos y navegación

8.1 Aceptar el formulario

8.2 Un evento en un botón

8.3 Un evento en un check box

9. Conclusiones

10. Sobre el autor

1. Introducción

En Autentia (https://www.autentia.com) trabajamos día a día para mejorar la calidad del software (tanto de nuestros desarrollos como los de nuestros clientes). Para esto consideramos que es fundamental el uso de patrones.

Uno de los patrones más conocidos en el desarrollo web es el patrón MVC (Modelo Vista Controlador). Este patrón nos permite/obliga a separar la lógica de control (sabe que cosas hay que hacer pero no como), la lógica de negocio (sabe como se hacen las cosas) y la lógica de presentación (sabe como interactuar con el usuario).

Utilizando este tipo de patrones conseguimos: más calidad, mejor mantenibilidad, perder el miedo al folio en blanco (tengo un patrón a seguir al empezar un proyecto), … pero una de las cosas más importantes es la normalización y estandarización del desarrollo de Software.

Mi labor en Autentia me ha permitido colaborar con numerosas empresas (grandes y pequeñas), y se podría decir que en casi todas ellas cada equipo de desarrollo hacía las cosas de manera totalmente diferente. Esto no se debería permitir, es un gasto de esfuerzo y conocimiento. Cada vez que se quiere pasar una persona de un equipo a otro el coste es muy elevado (coste de aprendizaje, tiempo, el tiempo es oro).

Por eso en este tutorial vamos a ver un framework de desarrollo que sigue el patrón MVC. Los frameworks son muy útiles ya que nos permiten no tener que reinventar la rueda cada vez. Es decir el framework no sólo sigue el patrón, sino que me da unas directrices de trabajo, y nos da gran parte del trabajo ya hecho (en forma de libreriás, asplicaciones, …).

JSF (Java Server Faces) es un framework de desarrollo basado en el patrón MVC (Modelo Vista Controlador).

Al igual que Struts, JSF pretende normalizar y estandarizar el desarrollo de aplicaciones web. Hay que tener en cuenta JSF es posterior a Struts, y por lo tanto se a nutrido de la experiencia de este, mejorando algunas sus deficiencias. De hecho el creador de Struts (Craig R. McClanahan) también es líder de la especificación de JSF.

A continuación presento algunos de los puntos por los que JSF me parece una tecnología muy interesante (incluso más que Struts 😉

  • Hay una serie de especificaciones que definen JSF:

JSR 127 (http://www.jcp.org/en/jsr/detail?id=127)
JSR 252 (http://www.jcp.org/en/jsr/detail?id=252)
JSR 276 (http://www.jcp.org/en/jsr/detail?id=276)

  • JSF trata la vista (el interfaz de usuario) de una forma algo diferente a lo que estamos acostumbrados en aplicaciones web. Sería más similar al estilo de Swing, Visual Basic o Delphi, donde la programación del interfaz se hace a través de componentes y basada en eventos (se pulsa un botón, cambia el valor de un campo, …).
  • JSF es muy flexible. Por ejemplo nos permite crear nuestros propios componentes, o crear nuestros propios “render” para pintar los componentes según nos convenga.
  • Es más sencillo.

JSF no puede competir en madurez con Struts (en este punto Struts es claro ganador), pero si puede ser una opción muy recomendable para nuevos desarrollos, sobre todo si todavía no tenemos experiencia con Struts.

2. Entorno

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil Ahtex Signal X-9500M (Centrino 1.6 GHz, 1024 MB RAM, 60 GB HD).
  • Sistema Operativo: GNU / Linux, Debian Sid (unstable), Kernel 2.6.12, KDE 3.4
  • Máquina Virtual Java: JDK 1.5.0_03 de Sun Microsystems
  • Eclipse 3.1
  • Tomcat 5.5.9
  • MyFaces 1.0.9

3. Instalación de MyFaces

Una de las ventajas de que JSF sea una especificación es que podemos encontrar implementaciones de distintos fabricantes. Esto nos permite no atarnos con un proveedor y poder seleccionar el que más nos interesa según: número de componentes que nos proporciona, rendimiento, soporte, precio, política,

En nuestro caso vamos a usar el proyecto de Apache: MyFaces. Esta es una implementación de JSF de Software Libre que, además de cumplir con el estándar, también nos proporciona algunos componentes adicionales.

Descargamos myfaces-*.tgz de http://myfaces.apache.org/binary.cgi

Una vez descargado lo descomprimimos en un directorio.

Creamos un proyecto web en nuestro Eclipse: File –> New –> Project… –> Dynamic Web Project

Copiamos las librerías necesarias para usar JSF

$ cp <MYFACES_HOME>/lib/*
<MYPROJECT_HOME>/WebContent/WEB-INF/lib

donde <MYFACES_HOME> es el directorio donde hemos descomprimido myfaces-*.tgz y <MYPROJECT_HOME> es el directorio de nuestro proyecto de Eclipse.

Nuestro proyecto tendrá el siguiente aspecto:

También modificamos nuestro web.xml para que quede de la siguiente manera:

Se puede ver como el servlet de JSF recogerá todas las peticiones que acaben en “.jsf”.

4. Vamos al lío

Ya tenemos instalada una implementación de JSF. Ahora vamos a hacer una pequeña aplicación de ejemplo, para demostrar como funcionan las principales características de JSF (el movimiento se demuestra andando).

Primero vamos a describir nuestra aplicación de ejemplo (este ejemplo está basado en los ejemplos del tutorial Core-Servlets JSF Tutorial by Marty Hall –
http://www.coreservlets.com/JSF-Tutorial), presentando cada uno de los ficheros que forman parte de ella, junto con una captura de las ventana correspondiente (si tiene representación visual), y junto a su código fuente.

Después, en cada capítulo, explicaremos concretamente cada uno de los puntos de la aplicación. Al final del tutorial habremos visto:

  • Internacionalización (i18n)
  • Recuperación de los datos del formulario
  • Validaciones
  • Gestión de eventos
  • Navegación

4.1 customize.jsp

Dentro de la carpeta WebContent.

Esta será la ventana inicial de la aplicación. Es un simple formulario de entrada donde podemos personalizar los colores de nuestro CV (“Resume” en ingles), introducir nuestro nombre, la edad, y nuestra profesión.

En las siguientes imágenes se puede apreciar la aplicación en distintos lenguajes, y como se muestran los errores de validación.

En el código podemos ver como se utilizan librerías de etiquetas para “pintar” los distintos componentes. En este sentido JSF es muy similar a Struts, ya que el interfaz de usuario se implementa con JSPs, la ventaja de JSF frente a Struts es que JSF desde un principio está pensado para que las herramientas de desarrollo faciliten la elaboración del interfaz de forma visual. Dentro de las este tipo de herramientas (también permiten modificar los ficheros de configuración de JSF de forma visual) podemos encontrar, entre otras muchas:

4.2 same-color.jsp

Dentro de la carpeta WebContent.

Esta pantalla muestra un mensaje de error cuando se selecciona el mismo color para el fondo y para las letras.

4.3 show-preview.jsp

Dentro de la carpeta WebContent.

Muestra un borrador del CV según lo que hemos puesto en el formulario de la ventana inicial.

4.4 Ficheros de
recursos

Dentro de la carpeta JavaSource.

Estos ficheros son los que contienen la traducción de los textos dependiendo del lenguaje.

MessageResources_es.properties

MessageResources_en.properties

4.5 ResumeBean.java

Dentro de la carpeta JavaSource/com/autentia/jsfexample.

Este bean es el que guardará toda la información
recogida en el formulario. El equivalente en Struts sería una
mezcla entre la clase de formulario (ActionForm) y la clase acción
(Action). Esto lo podríamos ver como una ventaja ya que
simplifica el código, aunque si nos gusta más la
aproximación de Struts también es posible hacer dos
clases distintas en JSF (ejemplo de la mayor flexibilidad de JSF
frente a Struts).

También podemos observar que la clase no define ninguna
relación de herencia (en Struts extendemos de Action o
ActionForm). Esto es una ventaja ya que hay menos acoplamiento entre
nuestro modelo y JSF.

4.6 faces-config.xml

Dentro de la carpeta WebContent/WEB-INF.

Este fichero es donde configuramos JSF. Es como el “pegamento” que une modelo, vista y controlador. El equivalente en Struts sería el fichero struts-config.xml.

En este fichero por un lado declaramos los beans que vamos a utilizar para recoger la información de los formularios (en el struts-config.xml teníamos una sección similar), y por otro lado las reglas de navegación (en el struts-config-xml se podría comparar con la definición de forwards de las acciones).

5. Internacionalización (i18n)

La internacionalización nos va ha permitir mostrar la aplicación según el idioma del usuario. Para ello en el fichero faces-config.xml vamos a especificar que localizaciones soporta la aplicación, y cual es la localización por defecto:

A continuación mostramos un ejemplo de uso de i18n, que podemos encontrar en el fichero customize.jsp:

En el ejemplo se puede ver como lo primero que se hace es cargar el fichero de recursos. El sistema se encargará de seleccionar el fichero apropiado según el lenguaje, y si se trata de un lenguaje no soportado se seleccionará el idioma por defecto.

Una vez cargado el fichero de recursos es tan facil usarlo como “${msg.customize_title}” donde “msg” es el identificador que le hemos dado al fichero de recursos y “cutomize_title” es la clave del mensaje que queremos mostrar.

6. Recuperando los valores del formulario

Desde el punto de vista del interfaz (customize.jsp) tenemos líneas del estilo:

Esto dibujará un campo de entrada y los valores introducidos los guardará en la propiedad “name” del bean “resumeBean”. Este bean es el que hemos definido en el fichero faces-config.xml:

Por supuesto la clase com.autentia.jsfexample.ResumeBean tendrá métodos get/set públicos para acceder a “name”.

Es importante destacar como en el fichero faces-config.xml se define el scope del bean. JSF buscará el bean en ese scope, y si no lo encuentra lo creará y lo guardará en ese scope.

Ojo porque JSF sólo se encarga de crear el bean, pero no de su destrucción, así que todo lo que guardemos en sesión o aplicación allí se quedará hasta que nosotros lo quitemos. Si queremos quitar un bean de la sesión (muy recomendable cuando el objeto ya no es necesario) podemos hacer algo como:


7. Validación de los campos de entrada

7.1 Especificar las validaciones

En la vista encontramos cosas como:

Se ve como al definir el campo de entrada se está especificando que es obligatorio “required = true”. Otro ejemplo más sería:

Aquí se puede ver como, además de hacer que el campo sea obligatorio, se está fijando un valor mínimo y un valor máximo. Además como la propiedad “age” del bean “resumeBean” es de tipo “int” también se hará comprobación del tipo del valor introducido por el usuario, es decir, si el usuario no introduce un número, dará un error al validar.

Al igual que en Struts disponemos de multitud de validaciones predefinidas. Además también contamos con API que podemos implementar para hacer nuestras propias validaciones.

Esta forma de especificar las validaciones es más sencilla que en Struts, ya que se hace directamente en la definición del campo de entrada, y no en un fichero separado. Además la validación no está asociada a ningún bean en concreto como pasa en Struts, con lo que resulta más flexible.

Actualmente JSF no dispone de validaciones en cliente con JavaScript, pero esto no es un problema ya que si queremos usar esta funcionalidad siempre podemos usar Apache Commons Validator.


7.2 Mostrar los errores de la validación

Para mostrar los errores de la validación basta con escribir la siguiente línea donde queremos mostrar los errores:

En nuestro caso estamos usando el componente con funcionalidad ampliada que proporciona MyFaces (x:messages). Este funciona igual que el definido por el estándar, pero al mostrar el error, en vez de aparecer el id del campo de entrada, aparece el valor de la etiqueta asociada. Con esto conseguimos que el mensaje sea más legible para el usuario, ya que se tendrá en cuenta el lenguaje en el que se está viendo la página.

Para escribir la etiqueta del campo de entrada usaremos:

donde el atributo “for” es el identificador del campo de entrada.

Por supuesto, al igual que en Strutrs, podemos redefinir los mensaje de error de las validaciones.


8. Gestión de eventos y navegación

En este apartado vamos a ver como gestionamos cuando un usuario pulsa un botón o cambia el valor de un campos de entrada, y como afecta ese evento a la navegación de la aplicación.

Con JSF todos los eventos se gestionan en el servidor, pero no hay ninguna restricción para tratar en cliente con JavaScript los eventos que afectan a como se visualiza el interfaz de usuario.

8.1 Aceptar el formulario

En nuestro ejemplo encontramos un par de botones, vamos a fijarnos primero en el botón de “Previsualizar”. Este botón sería el que típicamente acepta el formulario, manda los datos al servidor, y nos da paso a la siguiente pantalla.

La línea que define el botón y su comportamiento es:

Se puede ver como el atributo “actión” define el método que se ha de invocar. En nuestro ejemplo el método “showPreview” del bean “resumeBean”. Lo importante de este tipo de métodos es que tienen que devolver un String indicando a donde hay que saltar.

Esto enlaza con las reglas de navegación que tenemos en el fichero faces-config.xml:

Si estamos en la página “customize.jsp” y el método devuelve el String “same-color” saltaremos a la página “same-color.jsp”. Pero si el método devuelve el String “success” saltaremos a la página “show-preview.jsp”. Como ya adelantábamos, es muy similar al funcionamiento de los forward de Struts, tiene la ventaja de que nuestro bean no tiene que extender de ninguna clase en concreto.

No siempre es necesario invocar a un método para activar la regla de navegación. Esto sólo será necesario para una navegación dinámica donde, dependiendo de alguna condición, saltaremos a una página o a otra. Si la navegación es estática, es decir siempre saltamos a la misma página, no haría falta implementar ningún método, y bastaría con poner:

8.2 Un evento en un botón

Podemos ver este tipo de eventos como acciones que implican cambios sobre el interfaz de usuario, pero todavía no hacemos la aceptación y procesamiento de los datos del formulario.

Tenemos el ejemplo del botón “Desactivar configuración de color”. Cuando el usuario pulse este botón se desactivarán las listas desplegables que hay sobre él, y cambia el texto del propio botón a “Activar configuración de color”.

Para conseguir que cambie le texto se puede ver como, en vez de usar directamente i18n, le pedimos el valor al propio bean con “#{resumeBean.colorSupportLabel}”.

Con “immediate=’true’” conseguimos que no se ejecuten las validaciones.

Con el atributo “actionListener” estamos definiendo quien atenderá el evento cuando se pulse el botón. En nuestro ejemplo es el método “toggleColorSupport” del bean “resumeBean”. Este tipo de métodos no devuelven nada y tienen un único parámetro de tipo “ActionEvent”.

Este método simplemente cambia el valor de la propiedad “isColorSupported”. El valor de esta propiedad es consultado cuando se va a pintar la lista de selección, en el atributo “disabled”:

8.3 Un evento en un check box

En nuestro ejemplo tenemos un check box que cuando está seleccionado hace que los en vez de los nombres de los colores veamos su codificación RGB (Red Green Blue).

Este caso es un poquito más complicado, ya que la pulsación de un check box no supone el envío del formulario al servidor. En este caso utilizamos:

Nuevamente estamos utilizando un método que atiende el evento del cambio del valor del check box, lo definimos con el atributo “valueChangeListener”. Este tipo de métodos no devuelven nada y tienen un único parámetro de tipo “ValueChangeEvent”.

Volvemos a utilizar “immediate” para que no se ejecuten las validaciones.

Es fundamental el uso de “onchange=’submit()’”. Esta es la principal diferencia con el caso anterior, y es lo que nos permite que el procesamiento del evento se haga de forma inmediata una vez el usuario pulsa sobre el check box.

9. Conclusiones

Si os habéis fijado, con JSF no hemos trabajamos con objetos de tipo HttpSession, HttpServletRequest, … esto es una ventaja ya que no hay prácticamente acoplamiento entre nuestra aplicación y el hecho de que el interfaz de usuario se a través de HTTP.

La elección de MyFaces como implementación de JSF no es casual. El hecho de que MyFaces sea Software Libre nos permite no perder las ventajas que nos daba Struts en este sentido. Es decir, independencia tecnológica, acceso al código y modificación del mismo si fuera necesario, nulo coste para acceder a esta tecnología, …

Además la comunidad de Apache está haciendo un estupendo trabajo con MyFaces (como ya nos tienen acostumbrados en el resto de proyectos) ya que además de los componentes del estándar, nos ofrecen una implementación mejorada de los mismos, y unos cuantos controles adicionales al estándar.

Aunque este tutorial no deja de ser una introducción a JSF, habéis podido ver que JSF surge como un framework muy prometedor, y una opción muy recomendable para nuevos desarrollos.

Pero ojo, ningún framework resuelve todas las problemáticas. El ejemplo más sencillo para comprender esta afirmación es pensar en un aplicación web y en un portal. En el primer caso el usuario interactúa con la aplicación introduciendo unos datos y esperando obtener unos resultados, en el segundo caso el usuario puede navegar por distintas pantallas de información, done esta información seguramente cambie a lo largo del tiempo (cada día, semana, mes, …).

Para las aplicaciones web pueden ser muy convenientes frameworks como JSF, Struts, Spring, … Pero estos no nos servirán (o será muy trabajoso) para hacer portales. Para este segundo caso sería más adecuado usar gestores de contenidos como Lenya, OpenCMS, …

Por esto en Autentia solemos recomendar la elección de más de un framewrok, dependiendo de las necesidades.

10. Sobre el autor

Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software)

Dir. Implantación y Rendimiento

Formador en tecnologías J2EE, ADOO, UML

mailto:alejandropg@autentia.com

Autentia Real Business Solutions S.L.

http://www.autentia.com

2 Comentarios

  1. Voy a recomendar este tutorial a mis colegas, porque es de lo mejor que he visto en los últimos tiempos.
    Muy bien hecho Alejandro y muchas gracias,
    Jaime.

Dejar respuesta

Please enter your comment!
Please enter your name here