Java Server Faces Caractersticas Avanzadas 113

CIBERTEC
Captulo 2 Captulo 6
Captulo 6










J avaServer Faces. Caractersticas
avanzadas








Al finalizar el captulo, el alumno:


Comprende el ciclo de vida que maneja el framework cada vez que un
usuario enva datos al servidor.
Comprende como internacionalizar las aplicaciones de JSF.
Reconoce la forma de obtener los datos del entorno de ejecucin del
framework.


Temas:


1. Ciclo de vida.
2. FacesContext.
3. Internacionalizacin.
4. Binding Beans.
Java Server Faces Caractersticas Avanzadas 114
CIBERTEC


VI. Captulo No 6:








Java Server Faces Caractersticas Avanzadas 115
CIBERTEC

1. Ciclo de Vida








JavaServer Faces ofrece un ciclo de vida claro y bien establecido en donde los
requerimientos del usuario pasan por unas fases estndares.

El ciclo de vida de JSF empieza cuando un usuario enva un submit desde la pgina
web. Este requerimiento es tomado por el servlet de JSF y, de all, pasa por las
diferentes fases.

El resultado de completar un ciclo de vida es una respuesta hacia el usuario. Esta
respuesta puede ser una pgina JSF o algn otro tipo de archivo.

Como la mayora de componentes de JSF, el ciclo de vida tambin puede ser
personalizado y hasta se le pueden aadir listeners para realizar operaciones antes
y despus de cada fase. Otra de las personalizaciones que se le pueden hacer al
ciclo de vida es terminarlo cuando el programador desee.


Java Server Faces Caractersticas Avanzadas 116
CIBERTEC





Las fases del ciclo de vida son las siguientes:


Restore View

El servidor recibe una llamada y recompone los objetos de la vista en el servidor.
Examina si FacesContext tiene un UIViewRoot en caso de
tenerlo:

- Le asigna el locale correspondiente (internacionalizacin).
- Para cada valor en el rbol mira si tiene un valuebinding
asociado a binding y si lo tiene llama a setValue() pasando la
instancia en donde se encontr.
- No se realizan ms acciones.
- Se crea el viewID de la URI y de los valores de prefijo:
ViewHandler.DEFAULT_SUFFIX_NAME.

Java Server Faces Caractersticas Avanzadas 117
CIBERTEC

Llaman a viewHandler.restoreView() pasando la instancia FacesContext asociada a
la llamada y el viewID, consiguiendo el UIViewRoot como respuesta:

- En caso de devolver null no haba vista asociada por lo que se crea una y se
pasa al renderResponse. Se llama a ViewHandler.createView() y a
FacesContext .renderResponse().

Si la peticin no contiene parmetros de llamada ni datos en POST se llama a
renderResponse.

Se almacena el UIViewRoot en el FacesContext.
Se determina el valuebinding para cada atributo binding y se llama al setValue.
Al final de esta fase tenemos recuperado el viewRoot que haba y si acaso se ha
creado uno nuevo.


Apply Request Values

Da la oportunidad a los componentes a actualizar sus valores con los valores que
llegan de la request.
Se llama al mtodo processDecodes() de todos los componentes del rbol
UIViewRoot.
Los componentes que implementan ActionSource que reconocen que fueron
activados encolan su evento. Estos eventos son notificados al final de esta fase.


Process Event

Todo error producir un mensaje que se encolar en el FaceContext, y el
componente que la lanza ser marcado como invalido.
En cualquier momento si nuestra lgica en los decode, o en los eventos llama a
responseComplete en FacesContext entonces se termina inmediatamente el
procesado del request.
Si se llama a renderResponse en el FacesContext, se transfiere el control a la fase
de Render Response. En caso contrario, pasamos a la fase siguiente.


Process Validations

Se procesan las validaciones llamando a processValidators.
Cualquier fallo en la validacin coloca un mensaje de error en el FacesContext y la
propiedad valid del componente se pone a false.
En cualquier validador puede llamar a responseComplete o a renderResponse de
FacesContext.


Update Model Values

Llegados a esta fase se asume que los contenidos son sintcticamente y
semnticamente correctos. Tambin se asume que el valor local de los
componentes ha sido actualizado.

Es el momento de actualizar los datos del modelo de la aplicacin. Esto se produce
recursivamente llamando a UlComponent.processUpdates. La actualizacin dentro
de un componente se realiza llamando al mtodo updateModel.

Java Server Faces Caractersticas Avanzadas 118
CIBERTEC
Durante la actualizacin los eventos son encolados hasta la finalizacin de la fase
donde se procesan.

Al finalizar esta fase, los valores del modelo de datos han sido actualizados y los
valores de los componentes han sido vaciados. Cualquiera de nuestros mtodos
podra llamar a responseComplete o a renderResponse.


Invoke Application

Si se alcanza esta fase, se asume que la actualizacin del modelo ha sido
completada.
Se llama al mtodo processApplication de UIViewRoot.
Se llama a todos los eventos encolados con
phaseId.INVOKE_APPLICATION.
Excepcionalmente se podra llegar a cambiar el actionListener por defecto con
setActionListener.


Render Response

Hace que la respuesta sea renderizada al cliente.
Hace que el estado de la respuesta sea guardado para ser procesado en llamadas
sucesivas.

Cuando un componente de rbol es seleccionado para renderizarse se llama a su
mtodo de encodexxx().
Para los elementos que implementan ValueHolder se ha de producir su conversin.

Antes de completarse el estado de la vista ha de ser guardado usando los mtodos
de la clase StateManager.
Esta informacin ha de estar disponible para que Restore View pueda acceder a ella
en sucesivas llamadas.





Java Server Faces Caractersticas Avanzadas 119
CIBERTEC

Los pasos del ciclo de vida se ejecutan dependiendo de si la peticin se origin o no
desde una aplicacin JavaServer Faces y adems, si la respuesta es o no, generada
con la fase de renderizado del ciclo de vida de JavaServer Faces.





Una aplicacin JavaServer Faces soporta dos tipos diferentes de respuestas y dos
tipos diferentes de peticiones; la idea es que en una aplicacin JSF se pueden
mezclar pginas JSF y JSP (no-JSF) y, segn se pidan y/o se devuelvan una u
otras, se tendrn diferentes respuestas y/o peticiones:

Respuesta Faces:
Una respuesta servlet que se gener mediante la ejecucin de la fase
Renderizar la Respuesta del ciclo de vida, de procesamiento de la respuesta.

Respuesta No-Faces:
Una respuesta generada por el servlet en la que no se ha ejecutado la fase
Renderizar la Respuesta. Por ejemplo, una pgina JSP que no incorpora
componentes JavaServer Faces.

Peticin Faces:
Una peticin al servlet que fue enviada desde una Respuesta Faces
previamente generada. Por ejemplo, un formulario enviado desde un
componente de interfaz de usuario JavaServer Faces, donde la URI de la
peticin, identifica el rbol de componentes JavaServer Faces para usar el
procesamiento de peticin.

Peticin No-Faces:
Una peticin al servlet que fue enviada a un componente de aplicacin como
un servlet o una pgina JSP, en vez de directamente a un componente
JavaServer Faces.



Java Server Faces Caractersticas Avanzadas 120
CIBERTEC

2. FacesContext








Toda llamada o request tiene asociado un FaceContext al hilo de llamada. Un
ejemplo de FacesContext es que se asocia a una solicitud concreta a principios del
procesamiento de solicitudes, mediante una llamada a la getFacesContext () de la
instancia FacesContextFactory, las cuales estn asociadas a la aplicacin Web
actual.

El FaceContext solo debe existir durante la request hasta que se llame a su mtodo
release. No se le debe referenciar por un objeto que tenga una vida ms larga que
la request.



Java Server Faces Caractersticas Avanzadas 121
CIBERTEC

Contiene toda la informacin relativa al estado en la request y la renderizacin de la
respuesta.




Encapsula el elemento raz visual ViewRoot.

Encapsula los posibles mensajes que se generan en los
validadores/conversores/manualmente para ser mostrados en las pginas JSF.

Nos permite acceder al Singleton de Application.

Encapsula ResponseWriter -salida de caracteres- y ResponseStream salida
binaria-. Como flujos de escritura para los renderizadores.

Nos permite acceder a ExternalContext, el cual da acceso al entorno
independientemente de estar en un contenedor de servlets o de portlets.

Una de las partes importantes que tiene el FacesContext es que permite acceder a
todo el entorno de informacin que tendramos como servlet (request y response).

Java Server Faces Caractersticas Avanzadas 122
CIBERTEC

3. Internacionalizacin








Como todo framework importante en Java, JSF maneja la internacionalizacin de
las aplicaciones mediante las clases estndares del JDK, las cuales utilizan los
archivos de *.properties.

La idea de la internacionalizacin es tener una sola pgina de soporte para mostrar
en todos los lenguajes que la aplicacin maneje. Para realizar esto se deben crear
archivos planos que contengan los mensajes de cada uno de los idiomas a
mostrarse.






Java Server Faces Caractersticas Avanzadas 123
CIBERTEC




Uno de los primeros pasos a realizar para internacionalizar una aplicacin es la de
configurar el archivo de mensajes dentro del archivo de configuracin del JSF. Esto
se hace mediante la inscripcin del resource-bundle en el cual se debe especificar el
nombre del archivo fsico y un alias con el cual se invocar en el sistema.

Otro de los pasos a realizar es el de cambiar los mensajes que se mostrarn al
usuario en las etiquetas JSF para que invoquen al archivo de mensajes en vez de
tener los mensajes en duro.

Despus se debe crear en los archivos de mensajes, las claves y las descripciones
de los mensajes a ser mostrados.




Dentro de las clases estndares que utiliza JSF para la internacionalizacin, se
encuentra la Locale, la cual es utilizada para representar el idioma en el cual el
sistema ser mostrado.

Para poner ms de un lenguaje en la aplicacin, se debe crear los archivos con el
mismo nombre que el de mensajes seguidos por un guion bajo y 2 caracteres que
representan el cdigo ISO del idioma.

Java Server Faces Caractersticas Avanzadas 124
CIBERTEC
Por ejemplo, si el sistema va a soportar los idiomas ingls y francs, entonces se
deben crear los archivos con el nombre seguido por _en y _fr.





El ltimo paso es inscribir en el archivo de configuraciones los idiomas que
soportar el sistema para que as directamente el JSF haga el cambio de idioma en
las pginas JSF.





Normalmente el sistema debe soportar que el usuario cambie a su gusto el idioma
en el cual quiere ver sus mensajes. Para realizar esto se debe forzar a la aplicacin
a tener un idioma programticamente.

Esto se puede realizar de las 3 formas en las que se muestra en el grfico.

Java Server Faces Caractersticas Avanzadas 125
CIBERTEC

4. Binding Beans








JSF trabaja sus controles con clases internas que realizan las funcionalidades del
control dentro del framework.

El framework da la facilidad de manipular estas clases y realizar trabajos sobre
ellas. Para poder asociar las clases a los controles que se colocan en las pginas
JSF, se crean los Binding Beans.

Los Binding Beans (tambin llamados Backing beans) representan al componente
completo y no solo al valor (como lo hacen los managed bean). Los Binding Beans
tambin puede definir los mtodos que realizan funciones asociadas a un
componente de control de eventos, el proceso de navegacin adems de la
validacin.


Java Server Faces Caractersticas Avanzadas 126
CIBERTEC




Como se aprecia en la imagen, para poder asociar un componente a su clase, se
debe colocar en la propiedad binding del componente una referencia a la
propiedad que ser amarrada al componente.

La propiedad que recibir al componente dentro del Bean debe ser de la clase a la
cual pertenece. Recordemos que los controles de JSF existen en un rbol que se
inicializa cuando empieza el ciclo de vida del framework.

En el ejemplo que se aprecia en la imagen, podemos ver como se asocia una
propiedad UIInput a una caja de texto. Con esto se logra que el programador pueda
tener una referencia al control completo y no solo al valor como cuando se hace
referencia mediante la propiedad value.