Está en la página 1de 5

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.5 1.2 2.5 2.1 1.2


1.2.2

RichFaces 1.5 1.2 2.5 2.1 1.2


3.2.0

MyFaces 1.3 1.1 2.3 1.2 1.0


1.1.4 enlace
al repositorio

Tomahawk 1.3 1.1 2.3 1.2 1.1


1.1.6
• 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

También podría gustarte