Capitulo 6 - Características Avanzadas JSF

Java Server Faces – Características Avanzadas 113

CIBERTEC

Capítulo 2Capítulo 2Capítulo 6Capítulo 6Capítulo 6

JavaServer Faces. Características avanzadas

Al finalizar el capítulo, el alumno: Comprende el ciclo de vida que maneja el framework cada vez que un

usuario envía datos al servidor.

Comprende como internacionalizar las aplicaciones de JSF.

Reconoce la forma de obtener los datos del entorno de ejecución del

framework.

Temas: 1. Ciclo de vida.

2. FacesContext.

3. Internacionalización.

4. Binding Beans.


CIBERTEC

VI. Capítulo No 6:


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 estándares. El ciclo de vida de JSF empieza cuando un usuario envía un submit desde la página 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 página JSF o algún otro tipo de archivo. Como la mayoría de componentes de JSF, el ciclo de vida también puede ser personalizado y hasta se le pueden añadir listeners para realizar operaciones antes y después de cada fase. Otra de las personalizaciones que se le pueden hacer al ciclo de vida es terminarlo cuando el programador desee.


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 (internacionalización). - 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 más acciones. - Se crea el viewID de la URI y de los valores de prefijo:

ViewHandler.DEFAULT_SUFFIX_NAME.


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 había vista asociada por lo que se crea una y se pasa al renderResponse. Se llama a ViewHandler.createView() y a FacesContext .renderResponse().

Si la petición no contiene parámetros 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 había 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 método 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 lógica 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 validación 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 sintácticamente y semánticamente correctos. También se asume que el valor local de los componentes ha sido actualizado. Es el momento de actualizar los datos del modelo de la aplicación. Esto se produce recursivamente llamando a UlComponent.processUpdates. La actualización dentro de un componente se realiza llamando al método updateModel.


CIBERTEC

Durante la actualización los eventos son encolados hasta la finalización 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 métodos podría llamar a responseComplete o a renderResponse. Invoke Application Si se alcanza esta fase, se asume que la actualización del modelo ha sido completada. Se llama al método processApplication de UIViewRoot. Se llama a todos los eventos encolados con phaseId.INVOKE_APPLICATION. Excepcionalmente se podría 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 método de encodexxx(). Para los elementos que implementan ValueHolder se ha de producir su conversión. Antes de completarse el estado de la vista ha de ser guardado usando los métodos de la clase StateManager. Esta información ha de estar disponible para que Restore View pueda acceder a ella en sucesivas llamadas.


CIBERTEC

Los pasos del ciclo de vida se ejecutan dependiendo de si la petición se originó o no desde una aplicación JavaServer Faces y además, si la respuesta es o no, generada con la fase de renderizado del ciclo de vida de JavaServer Faces.

Una aplicación JavaServer Faces soporta dos tipos diferentes de respuestas y dos tipos diferentes de peticiones; la idea es que en una aplicación JSF se pueden mezclar páginas JSF y JSP (no-JSF) y, según se pidan y/o se devuelvan una u otras, se tendrán diferentes respuestas y/o peticiones: • Respuesta Faces:

Una respuesta servlet que se generó mediante la ejecución 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 página JSP que no incorpora componentes JavaServer Faces.

• Petición Faces:

Una petición 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 petición, identifica el árbol de componentes JavaServer Faces para usar el procesamiento de petición.

• Petición No-Faces:

Una petición al servlet que fue enviada a un componente de aplicación como un servlet o una página JSP, en vez de directamente a un componente JavaServer Faces.


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 están asociadas a la aplicación Web actual. El FaceContext solo debe existir durante la request hasta que se llame a su método release. No se le debe referenciar por un objeto que tenga una vida más larga que la request.


CIBERTEC

Contiene toda la información relativa al estado en la request y la renderización de la respuesta.

Encapsula el elemento raíz visual ViewRoot. Encapsula los posibles mensajes que se generan en los validadores/conversores/manualmente para ser mostrados en las páginas 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 información que tendríamos como servlet (request y response).


CIBERTEC

3. Internacionalización

Como todo framework importante en Java, JSF maneja la internacionalización de las aplicaciones mediante las clases estándares del JDK, las cuales utilizan los archivos de *.properties. La idea de la internacionalización es tener una sola página de soporte para mostrar en todos los lenguajes que la aplicación maneje. Para realizar esto se deben crear archivos planos que contengan los mensajes de cada uno de los idiomas a mostrarse.


CIBERTEC

Uno de los primeros pasos a realizar para internacionalizar una aplicación es la de configurar el archivo de mensajes dentro del archivo de configuración del JSF. Esto se hace mediante la inscripción del resource-bundle en el cual se debe especificar el nombre del archivo físico 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 mostrarán al usuario en las etiquetas JSF para que invoquen al archivo de mensajes en vez de tener los mensajes en duro. Después se debe crear en los archivos de mensajes, las claves y las descripciones de los mensajes a ser mostrados.

Dentro de las clases estándares que utiliza JSF para la internacionalización, se encuentra la Locale, la cual es utilizada para representar el idioma en el cual el sistema será mostrado. Para poner más de un lenguaje en la aplicación, se debe crear los archivos con el mismo nombre que el de mensajes seguidos por un guion bajo y 2 caracteres que representan el código ISO del idioma.


CIBERTEC

Por ejemplo, si el sistema va a soportar los idiomas inglés y francés, 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 páginas 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 aplicación a tener un idioma programáticamente. Esto se puede realizar de las 3 formas en las que se muestra en el gráfico.


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 páginas JSF, se crean los Binding Beans. Los Binding Beans (también llamados Backing beans) representan al componente completo y no solo al valor (como lo hacen los managed bean). Los Binding Beans también puede definir los métodos que realizan funciones asociadas a un componente de control de eventos, el proceso de navegación además de la validación.


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”.

Capitulo 6 - Características Avanzadas JSF

Documents

Transcript of Capitulo 6 - Características Avanzadas JSF