El ciclo de vida de una petición JSF

En el ciclo de vida de procesamiento de peticiones jsf se realizan todas las tareas de back-end que de otro modo debería realizar el programador. Procesa los parámetros de entrada y gestiona un conjunto de componentes del lado del servidor y los sincroniza para que lo vea el usuario en el navegador.

Realiza la mayoría de las operaciones del lado del servidor de una manera automática basada en eventos. Enlaza directamente campos con propiedades de una clase java, de modo que sincroniza beans del lado del servidor, con los componentes de UI que ve el usuario. Es lo que se conoce como “gestión de estado” y es la piedra angular de JSF.

No se almacena el estado, esto es, una transacción entre el cliente y el servidor, no almacena en memoria las transacciones anteriores. Jsf mantiene una vista en el lado del servidor que representa partes importantes del estado actual del cliente. Las fases del ciclo de vida son:

  •  Crea o restaura la vista → Crea o restaura un árbol de componentes (vista) del lado del servidor, que representan los componentes de interfaz de usuario del cliente. Las vistas se crean y almacenan en un contenedor de vistas llamado “FacesContext”. El desarrollador no se tiene que preocupar por si los datos se mezclan al realizar múltiples “request” ya que cada petición irá en su propio hilo.
  • Aplica los valores del “request” → Actualiza los componentes del lado del servidor con datos “frescos” que provienen del lado del cliente. Esto se hace a través de una invocación a “processDecodes()” en el árbol de componentes (UIViewRoot), lo que provocará que se llame de manera recursiva al método “processDecodes()”  de cada uno de los componentes hijo y los métodos “decode()” de los componentes UI. Los componentes UI que tienen el atributo “value”, como los campos de texto, etc., implementarán el interfaz “ValueHolder”, los componentes de formulario que tienen valores editables por el usuario, implementan “EditableValueHolder” y finalmente aquellos componentes que ejecutan acciones, como los botones o los links, implementarán “ActionSource”.   
  • Ejecuta las Validaciones → Procesa las validaciones y realiza la conversión de datos en su caso. Para hacer esto invoca al método “processValidators() de manera recursiva en el árbol de componentes (UIViewRoot). Cualquier componente que falle en la validación o en la conversión tendrá la propiedad “valid = false
  • Actualiza el modelo → Una vez que se pasan las validaciones y las conversiones, se realizan las actualizaciones de los objetos que modelan los datos en el lado del servidor (Managed Beans). El mecanismo es similar a los anteriores, se invoca al interfaz “processUpdates()” de manera recursiva en el árbol de componentes UIViewRoot
  • Invoca a la lógica de aplicación → En esta fase se invoca a los “action method”, esto es, al algún código que hemos configurado para que realice las acciones necesarias con los datos. Se invoca al método “processApplication()” del UIViewRoot y se transmite eventos en cola a cada componente que implemente “ActionSource”.
  • Devuelve la respuesta → Salva el estado y devuelve la respuesta al cliente para que los componentes sean representados. El mecanismo es similar al que hemos comentado anteriormente, se invocará en cascada a los métodos “encodeXX()” de cada componente. El lenguaje de “renderizado” puede ser cualquiera, html, xml, etc. Se almacena el estado de la vista para que pueda ser utilizado en las siguientes peticiones.
 El atributo “immediate”

Imaginemos que tenemos el formulario “mensaje.xhtml” que vimos en el artículo anterior ( Introducción a Jsf ), y queremos incluir un botón “Salir”, en la página de envío de mensajes, de modo que independientemente de lo que hayamos introducido en el formulario, se nos redirija a una página “inicio.xhtml”. Si añadimos en el formulario el botón de este modo:

Si lo dejamos simplemente así, tendremos un error, ya que el formulario será enviado y se procesarán los campos de entrada y las validaciones según el ciclo de vida que hemos visto anteriormente.

Si añadimos el atributo “immediate” con el valor “true” en un componente UICommand, como un botón, nos saltaremos las validaciones e iremos directamente a la página “inicio.xhtml”. En general, “immediate” disparará los eventos de acción inmediatamente antes de realizar la fase de validación y evitará la actualización de datos en el modelo:

Se puede aplicar el atributo “immediate = true” a los componentes que implementen “EditableValueHolder”, como ocurre con los campos de entrada, para que realicen la validación de manera inmediata. El uso típico de este mecanismo se da cuando queremos que unos campos del formulario se habiliten en función del contenido que tenga otro campo. Para que esto funcione habrá que configurar “listeners”.

Los “phase listeners” permiten ejecutar código java, en distintos puntos de las fases que definen el ciclo de vida. Por ejemplo, se puede mostrar un mensaje en función de los valores que se están introduciendo en tiempo de ejecución. Y esto es tan simple como crear clases Java que implementen el interfaz “PhaseListener” y registrar estas clases de manera programática o a través del archivo “faces-config.xml”.

Por otra parte el control de las excepciones se realiza a través de “ExceptionHandler” que manejará las excepciones que se puedan lanzar en el ciclo de vida Jsf.

Hasta aquí esta breve introducción sobre el ciclo de vida. En los próximos artículos seguiremos profundizando sobre el diseño da aplicaciones con Jsf y hablaremos sobre los facelets

5 comentarios:

  1. Aplica esto también para Prime Faces?

  2. Me ha servido mucho y aclarado cuaestiones que tenia en el aire acerca de JSF, gracias por tomarse el tiempo de realizar tan buenos articulos.

  3. Pingback: Introducción a JavaServer Faces (JSF) | Mindware SRL

  4. Pingback: Validación y Navegación en JSF | Mindware SRL

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *