CERCA SITEMAP 1280
Ultimo aggiornamento: 30 Agosto 2009

Ciclo di vita di una pagina JavaServer Faces

Il ciclo di vita di una pagina JavaServer Faces è simile a quello di una pagina JavaServer Pages ma risulta diviso in più fasi: Restore View, Apply Request Values, Process Validation, Update Model Values, Invoke Application, Render Response.
Ciclo di vita di una pagina javaserver faces
Ciclo di vita di una pagina JavaServer Faces
L'immagine mostra le fasi nelle quali è suddiviso il ciclo di vita di una pagina JavaServer Faces:
  • RestoreView
  • Apply Request Values
  • Process Validation
  • Update Model Values
  • Invoke Application
  • Render Response
Dopo ogni fase si ha la gestione degli eventi generati.
Inoltre una pagina JSF è rappresentata attraverso un albero di UIComponent chiamato view: durante il ciclo di vita JSF deve costruire la view considerando gli stati salvati dalle precedenti sottomissioni delle pagine.
Quando il client richiede una pagina l'implementazione JSF effettua diverse elaborazioni che vanno dalla validazione alla conversione dei dati, dalla gestione degli eventi alla costruzione della risposta.
Essenzialmente occorre distinguere fra due tipi di richieste: la richiesta iniziale e la richiesta postback.
La richiesta postback è la sottomissione di un form che è contenuto in una pagina che è stata precedentemente caricata dal browser come risultato della esecuzione della richiesta iniziale.
Quando il ciclo di vita gestisce una richiesta iniziale vengono eseguite esclusivamente le fasi Restore View e Render Response perchè non c'è alcun input utente da processare, viceversa nel caso di una richiesta postback vengono eseguite tutte le fasi.
Per visualizzare una risposta in un'altra pagina l'applicazione crea una nuova view e la memorizza nell'istanza FacesContext che rappresenta tutte le informazioni contestuali associate all'elaborazione di una richiesta entrante.
L'applicazione quindi acquisisce i riferimenti agli oggetti necessari alla view e chiama il metodo FacesContext.renderResponse il quale effettua il rendering della view.
Qualche volta un'applicazione potrebbe richiedere di essere reindirizzata ad una differente web-application o generare una risposta che non contiene alcun componente JSF: in questa situazione si salta la fase di rendering chiamando FacesContext.responseComplete.
Naturalmente la proprietà currentPhaseId del FacesContext, che rappresenta la fase in cui il ciclo di vita si trova, deve essere aggiornata appena possibile dall'implementazione.

Fase Restore View

Quando viene effettuata la richiesta di una pagina l'implementazione JSF avvia la fase Restore View.
Durante questa fase si procede alla costruzione della view della pagina, dei gestori degli eventi, dei validatori e dei componenti presenti nella vista.
La view viene quindi salvata nell'istanza FacesContext che contiene tutte le informazioni necessarie a processare una singola richiesta cui tutti i tag componenti dell'applicazione (gestori di eventi, convertitori e validatori) hanno accesso.
Se la richiesta per la pagina è una richiesta iniziale allora l'implementazione crea una view vuota e il ciclo di vita avanza alla fase di Render Response durante la quale la vista viene popolata dai componenti referenziati dai tag nella pagina, altrimenti la view corrispondente alla pagina è già esistente e durante questa fase l'implementazione JSF aggiorna tale vista utilizzando le informazioni di stato salvate sul client o sul server.

Fase Apply Request Values

In questa fase ogni componente dell’albero rappresentante la view estrae il suo nuovo valore dai parametri della richiesta utilizzando il metodo decode.
Se la conversione del valore fallisce allora viene generato un messaggio di errore (associato al componente) che viene accodato nel FacesContext: tale messaggio viene visualizzato durante la fase di Render Response insieme a tutti gli altri errori risultanti in fase di validazione.
Inoltre se un qualsiasi metodo decode o event listener chiama renderResponse su FacesContext l'implementazione salta direttamente alla fase Render Response.
Gli eventi accodati in questa fase vengono quindi inviati ai listener interessati, se qualche componente ha il suo attributo immediate settato a true allora validazione, conversione ed eventi associati vengono immediatamente processati.
A questo punto se l'applicazione necessita di un redirect o genera una risposta che non contiene alcun componente JSF allora è possibile invocare direttamente FacesContext.responceComplete.

Fase Process Validation

Durante questa fase JSF invoca tutti i metodi validate dei validatori registrati presso i componenti.
Questi esaminano gli attributi dei componenti che specificano le regole per la validazione e confrontano queste regole con i valori locali.
Se il valore locale non è valido allora l'implementazione JSF aggiunge un errore all'istanza FacesContext e il ciclo di vita avanza alla fase di Render Response così che la pagina possa essere renderizzata (e i messaggi di errore visualizzati).
Se qualsiasi metodo validate o event listener chiama FacesContext.renderResponse allora l'implementazione salta direttamente alla fase Render Response.
Se l'applicazione necessita di un redirect ad un'altra web-application o genera una risposta che non contiene alcun componente JSF allora è possibile invocare direttamente FacesContext.responseComplete.
Ancora una volta gli eventi accodati durante questa fase vengono inviati ai corrispondenti listener per le opportune elaborazioni.

Fase Update Model Values

Dopo la fase di validazione l’implementazione JSF procede percorrendo l’albero dei componenti e settando le corrispondenti proprietà degli oggetti lato server (backing beans) con i valori locali.In questa fase vengono aggiornale esclusivamente le proprietà dei bean che sono referenziate da uno specifico attributo di un componente.
Se i dati locali non possono essere convertiti nei tipi specificati dalle proprietà dei bean il ciclo di vita avanza alla fase di Render Response e la pagina viene visualizzata con gli errori che si sono verificati.
Se un qualsiasi metodo updateModels o listener chiama renderResponse su FacesContext l'implementazione salta direttamente alla fase di Render Response.
Gli eventi che sono stati accodati vengono quindi inviati ai corrispondenti listener.

Fase Invoke Application

Durante questa fase vengono gestiti gli eventi a livello di applicazione (ad esempio la sottomissione di un form).
In questa fase se un componente ha generato un evento (ad esempio il click su un bottone), il corrispondente evento viene inviato al listener che si occupa di gestirlo.
Quindi il controllo viene trasferito alla fase di Render Response.

Fase Render Response

Durante questa fase viene costruita la view e se si sta elaborando una richiesta iniziale i componenti rappresentati sulla pagina vengono aggiunti all'albero dei componenti.
Nel caso di una richiesta postback se sono stati accodati degli errori nelle fasi precedenti, se la pagina contiene tag message o messages ogni errore accodato viene visualizzato.
Una volta che il contenuto della view è stato renderizzato lo stato della risposta viene salvato e reso disponibile nella fase Restore View.