Descripción

JavaServer Faces es un estándar oficial JEE 5, se trata de un framework que define un modelo de

componentes de interfaz de usuario y de eventos.

JavaServer Faces nos permite manejar el estado de los componentes de interfaz de usuario, manejar sus

eventos, la validación y conversión del lado del servidor y centralizar la navegabilidad de las páginas de

nuestra aplicación, como se muestra en la siguiente imágen:

La especificación JSR 127 nos dice:

"JavaServer Faces es un entorno de desarrollo de interfaces de usuario para aplicaciones web creadas en

Java. Esta diseñado para facilitar el desarrollo y mantenimiento de las aplicaciones que se ejecutan en un

servidor y devuelven el resultado en forma de interfaz al cliente".

JSF es el marco estándar que proporciona Java para construir aplicaciones web y JEE 5, es un marco

desarrollo que sigue el patrón MVC, proporcionando una manera de validar datos, llamar a reglas de

negocio y devolver los resultados al cliente.

Estado

   Homologado en 2008Q2

   La última versión estable homologada es JSF 1.2

Enlaces principales← Página principal sobre JSF: http://java.sun.com/javaee/javaserverfaces/

← Información sobre el mundo JSF: http://www.jsfcentral.com/

Consideraciones Generales

JavaServer Faces proporciona :

← Una clara separación entre vista y modelo.

← Desarrollo basado en componente, no en peticiones.

← Las acciones del usuario se ligan muy fácilmente al código en el servidor.

← Creación de familias de componentes visuales para acelerar el desarrollo.

← Ofrece múltiples posibilidades de elección entre distintas implementaciones.

Para mayor información sobre las utilidades JSF, aquí

Las aplicaciones JSF siguen el patrón MVC, concretamente el modelo 2. Una típica aplicación JSF está

compuesta de las siguientes partes:

← JavaBeans para el manejo del comportamiento y del estado de la aplicación

En JSF los modelos son JavaBeans (POJO), no Actions, no Forms, no se extiende de ninguna clase, y lo

que es mejor, los recursos no se declaran expresamente, JSF los crea por nosotros.

← Un modelo de desarrollo orientado a los eventos

Por medio de Listener como es habitual en el desarrollo de pantallas de usuarios en Swing.

Struts es un entorno basado en las peticiones, actuando un servlet como controlador para redirigir la

llamada al recurso solicitado, JSF en un marco basado en Componentes, es decir son las peticiones URL

las que dirigen todo el desarrollo, todo el trabajo del programador va dirigido a controlar la petición y

crear la respuesta.

En entornos JSF la misión del desarrollador es crear , enlazar y modificar componentes, y estos

componentes son los que crean la respuesta que el cliente visualizará, que no son más que beans,

POJOs.

Estos beans se dividen en dos grupos, por un lado los encargados de responder a las peticiones de los

clientes. En la tecnología de visión que empleemos, se escribirá una llamada a estos objetos; es misión

de JSF, crear la petición, interceptarla y dirigirla a el objeto que nosotros le indiquemos. De esta

manera, programar en JSF en muy parecido a programar en Swing, toda la interacción del usuario con la

pantalla se controla con eventos.

Cuando el usuario pulsa un boton, lanza una peticion URL, sin que haya que programarla, que es

interceptada por un servlet controlador, este servlet redirige la información de la petición al objeto que

creó antes asociado al documento, comprueba la información que tenía antes y la contenida en la nueva

peticion, y genera los eventos necesarios según los cambios que haya habido, por ejemplo, el pulsar un

botón.

← Páginas que representan vistas

Estas páginas, una vez tratadas por el desarrollo JSF se representarán como objetos Java con una

estructura jerárquica en forma de árbol, para poder ser manipuladas por código, como haríamos en

una aplicación Swing, y asi añadir componentes adicionales, contenidos en tablas, etc.

JSF trae asociado un modelo de componentes para simplificar y acelerar el desarrollo de las

aplicaciones. Estos componentes se ordenan en una estructura jerárquica a la que se puede acceder y

modificar. Pero estos componentes no saben cómo dibujar la vista en el cliente, esa es la labor de otra

parte fundamenteal de la arquitectura JSF, los Renders.

La misión de los Renders es dibujar la información que, en forma jerárquica, se almacena en los

componentes la estructura de la página; de esta manera, es posible desarrollar una aplicación sin

conocer cual será el dispositivo final.

O lo que es mejor desarrollar una aplicación que se ve en dispositivos diferentes, solo cambiando el

Render, sin tocar ni una línea de la vista. O que el mismo objeto se vea como botón o como enlace, sólo

cambiando el render asociado a ese componente. Esta técnica es también de ayuda aunque sólo

desarrollemos con el lenguaje de marcado HTML en nuestra mente, pues es el Render_el encargado de

escribir gran parte del javascript que se necesita para el funcionamiento de la aplicación, y lo hace de

manera adecuada en cada navegador. JSF sólo obliga a que los desarrollos de la especificación traigan

un _Render para HTML.

Esta separación entre la definición de la página en el servidor y el Renderdel lenguaje de marcado

proporciona flexibilidad al desarrollador de componentes. Y permite que se cree un mercado de

componentes, tanto comerciales como de código abierto que van desde simples cajas de texto a

estructuras jerárquicas más complejas, menús, tablas con ordenación. Todo esto gracias al desarrollo de

un modelo de componentes estandard que respetan la especificación de JavaBeans, su estilo de eventos

y escuchadores y las fases definidas en el ciclo de vida.

Recomendaciones de uso

Recomendamos el desarrollo de aplicaciones web con JavaServer Faces si la aplicación tiene las

siguientes necesidades:

← Aplicaciones web de nuevo desarrollo, intranet o de internet con no demasiados usuarios.

← Aplicaciones web con necesidades de interfaz gráfico sofisticado.

Recomendaciones para construcción y diseño en aplicaciones JSF

Recomendamos también dividir los ficheros de configuración por funcionalidades ya que JSF nos lo

permite. Dedicar un fichero a escribir las reglas de navegación, y otro a la creación de los backing bean,

otro a la configuración del entorno, y así tantos como necesitemos.

Los puntos fuertes que hemos visto para JavaServer Faces son:

← Gran cantidad de componentes listos para usarse con funcionalidades avanzadas: Tomahawk y

RichFaces

← Permite encapsular otras tecnologías como Ajax en componentes JSF, haciendo su uso más facil

y productivo, al aislar al programador de ellas.

← Mas fácil de usar al aislar al desarrollador del API de Servlet. No request, no response, no

setAttibute. Sin embargo la curva de aprendizaje del modelo puede llegar a ser larga.

← Gran cantidad de herramientas para el desarrollo IDE en JSF al ser el estandar de Java: Eclipse y

el subproyecto Web Tools Project, JBoss Tools y NetBeans

Responsabilidades

La misión de JSF es aislar al programador tanto del tipo de cliente que hace la petición como del

protocolo usado para tal menester, permitiendo la creación de las vistas de una manera abstracta,

usando un modelo de componentes estable, estandar y extensible. De esta manera al aislarse del

entorno y sus particularidades, los desarrollos pueden ser más productivos, rápidos y eficazes, al usar

componentes ya probados.

Interacciones con otros subsistemas← MyFaces

← Facelets proporciona la posibilidad de escribir la capa cliente sin usar JSP.

← Spring y JSF

← Pruebas Unitarias JSF

← RichFaces

← Tomahawk

Restricciones y limitaciones

Ha habido un intento por tratar de que "convivan" JSF y Struts, es el caso de la librería struts-

faces(librería que no ha sido evaluada ni mucho menos homologada por arquitectura) no hay

documentación para esta librería y en el sitio oficial de Apache no se puede encontrar la versión que

correspondería para nuestra versión homologada de Struts 1.2.7

Componente JSDK JSF Servlet JSP JSTL

JBoss 4.2.2 1.5 1.2 2.5 2.1 1.2

MyFaces

1.2.2

1.5 1.2 2.5 2.1 1.2

RichFaces

3.2.0

1.5 1.2 2.5 2.1 1.2

MyFaces

1.1.4 enlace

al repositorio

1.3 1.1 2.3 1.2 1.0

Tomahawk

1.1.6

1.3 1.1 2.3 1.2 1.1

← El motor de servlet debe ser compatible con la especificación 2.3 y las JSP deben ser acordes a

la especificación 1.2.

← JSF únicamente soporta peticiones realizadas con POST.

← La especificación no obliga a que haya validaciones en el cliente, si bien MyFaces si que

porporciona esta posibilidad.

Ejemplos de uso

No aplica.

Documentación← Nuevas características en JSF 1.2

← Capítulos 10,11,12,13 y 14 del Tutorial de Java EE 5

http://java.sun.com/javaee/5/docs/tutorial/doc/bnaph.html

← Introducción a JSF http://www.coreservlets.com/JSF-Tutorial/

← Un artículo sobre JSF http://www-128.ibm.com/developerworks/library/j-jsf1/

← Tutoriales JSF

Especificaciones que definen JSF

← JSR 127

← JSR 252

← JSR 276 Labels parameters