Ciclo de vida en peticiones JSF
Antes de redactar artículos explicando como interactuar con ciertos componentes o como realizar diversas tareas, quería hablar un poco de algo que hay que tener muy en cuenta a la hora de desarrollar una aplicación usando JSF. El ciclo de vida de una petición JSF, son los diferentes caminos por donde irá pasando la petición realizada. Dependiendo de ciertos factores, este ciclo puede ser interrumpido o modificado. A continuación voy a explicar, a mi modo de ver lo que representa cada fase. Tambien conoceremos el funcionamiento de una propiedad que en ciertas ocasiones puede volvernos loco, como es la propiedad inmediate.
Fase 1: Restore View
Es esta primera fase se empieza a construir el árbol de componentes, llama al objeto UIViewRoot contenido en el FacesContext, del cual se obtendrá la información referente a la página. En esta fase el objeto UIViewRootse puede encontrar en tres estados diferentes:
New View: Construye un nuevo UIViewRoot y asocia los eventos y validadores a los componentes (Se hace una petición).
Initial View: Avanza directamente a la Fase 6. Esta vista se realiza cuando se carga la página por primera vez.
PostBack View: Cuando se vuelve atrás, se recupera la vista que esta guardada en el FacesContext.
Fase 2: Apply Request Values
En esta fase se asocian los valores que se encuentran en la petición a los componentes. Se comprueba el valor de la propiedad INMEDIATE que tienen los componentes. Esta propiedad sirve para capturar eventos y validaciones en esta fase del ciclo. El valor de la propiedad Inmediate es un Booleano:
False: Los valores simplemente se convierten, es decir, si para un campo se esperaba un entero se convierte el valor recogido a entero.Si se produce un error se guarda en el FacesContext y lo mostrará durante la Fase 6.
True: Le componentos valores se convierten y se validan. Si hay eventos asociados a eses se capturan también. Igual que anteriormente si se produce un error se mostrará en la Fase 6. Cuando captures el evento para estos casos, podemos obligar a que directamente pase a la Fase 6 y validamos/convertimos solo pequeñas partes de la página si se producen eventos.
Fase 3: Process Validations
En esta fase se comprueban las reglas de validación que tienen asociadas los componentes. Si se produce algún fallo en la validación se corta el ciclo y se pasa directamente a la Fase 6. Los mensajes de error generados se guarda en el FacesContext.
Fase 4: Update Model Values
En esta fase se actualizan el valor de las propiedades de los componentes en la clase Java. Se setean los valores de los componentes en el lado del servidor. Si no se validaron correctamente los componentes, obviamente los componentes del backing bean no se han actualizado.
Fase 5: Invoke Application
Se capturan los envíos y peticiones que realiza el Form. Como los valores ya han sido convertidos, validados y aplicados a los componentes, se ejecuta la lógica de la página. Se controlarían en esta fase los eventos, la navegación entre páginas, etc.
Fase 6: Render Response
Se muestra el UIViewRoot con todos los componentes en el estado que tengan asignado. Esto se recupera a través del FacesContext. Estas son las 6 fases por la que puede navegar la petición, si en cualquiera de ellas quisieramos pasar a la fase 6 directamente podríamos hacerlo mediante el metodo renderResponde() del FacesContext. Animo a crear un interceptor e ir probando con la propiedad inmediate y/o “cortocircuitar” fases para poder entenderlo mucho mejor. Como dije al principio del tema, esta explicado de la manera que yo lo he entendido, si alguien no está de acuerdo o quiere agregar más información, será bien recibida.
Tags: Java ServerFaces