JavaServer Faces標準請求/響應週期

JSF實現使用一個控制器servlet 來處理請求,而後執行 JSF 生命週期.如圖顯示了JSF 生命週期中的事件處理。 

上圖是正常的JSF組件的生命週期.一共12個.

記住,全部JSF事件都在服務器上執行,當在JSF頁面中提供一個事件處理程序時,就是告訴JSF實現當服務器處理頁面中的用於輸入時,應在生命週期的適當位置處理相應的事件.

從"應用請求值"階段開始,JSF實現會建立事件並在每一個生命週期階段期間將其添加到事件隊列中.

 

FacesContext 包含與單個 JavaServer Faces 請求的處理以及相應響應的呈現相關的全部每一個請求的狀態信息。它傳遞給請求處理生命週期的每一個階段，而且可能被修改。

注意事件監聽器可經過下列三種方式之一影響JSF生命週期： 

   (1) 讓生命週期正常進行。 

   (2)  調用FacesContext 類的RenderResponse 方法以忽略生命週期的其餘部分，直接跳轉到「呈現響應」階段。 

   (3)  調用FacesContext 類的responseComplete 方法以徹底略過生命週期的其餘階段。

兩個方法的具體資料以下:

abstract public void renderResponse()

通知 JavaServer faces 實現，完成請求處理生命週期的當前階段後，應該當即進入呈現響應階段，忽略還沒有執行的任何階段。

Throws IllegalStateException: 若是釋放此實例後調用此方法 

 

abstract public void responseComplete()

通知 JavaServer Faces 實現，已經生成了此請求的 HTTP 響應（如 HTTP 重定向），完成當前階段後，應該當即終止請求處理生命週期。

Throws IllegalStateException: 若是釋放此實例後調用此方法 

 

請求(通常不算在JSF生命週期中)

第一階段:還原視圖

第二階段:應用請求值+過程事件

第三階段:過程驗證+過程事件

第四階段:更新模型值+過程事件

第五階段:調用應用程序+過程事件

第六階段:呈現響應

響應(通常不算在JSF生命週期中)

首尾的請求,響應,如圖所示是單獨在外的.而剩下的就是真正意義上的JSF生命週期處理的步驟.

 

第一階段:還原視圖

在JSF生命週期的第一個階段"還原視圖"中,會有一個來自 FacesServlet 控制器的請求。控制器會對請求進行考查，並提取出視圖的 ID，這是由頁面的名字來肯定的.

JSF框架控制器使用這個視圖ID來爲當前的視圖查找組件。

若是這個視圖還沒有存在，那麼 JSF 控制器就會建立它.

若是這個視圖早已存在，那麼 JSF 控制器就會使用它.這個視圖包含全部的GUI組件.

(題外話:這也會形成ajax請求在生命週期中沒法重置掉頁面上input框的值,形成驗證錯誤後,再次打開dialog,錯誤值仍然存在.但仍然是利大於弊,只須要在JSF生命週期中修改JSF生命週期，在ajax驗證後再次進入進入生命週期，重置內容！ResetInputAjaxActionListener.就OK了).

生命週期的這個階段表示爲三個視圖實例:新視圖,原始視圖和後視圖，每一個視圖的處理方式都不相同。

FacesContext對象包含了 JSF 用來管理當前會話中當前請求的 GUI 組件狀態所須要的全部狀態信息。FacesContext 將視圖保存在本身的 viewRoot 屬性中；viewRoot 包含了當前視圖 ID 的全部 JSF 組件。

1.在 新視圖 的狀況中，JSF會構建Faces頁面的視圖，並將事件處理程序和驗證程序綁定到組件上。這個視圖被保存在FacesContext對象中。

2.在原始視圖的狀況中(第一次加載的是一個頁面),JSF 會建立一個空視圖.這個空視圖會在用戶事件產生時進行填充。JSF能夠直接從原始視圖過渡到進行響應的階段。

3.在後視圖(postback)的狀況中(用戶返回以前訪問過的頁面)，包含頁面的視圖早已經存在了，所以只須要進行恢復就能夠了。在這種狀況中，JSF 就使用現有視圖的狀態信息來重構狀態。後視圖的下一個階段是應用請求值。

第二階段:應用請求值+過程事件

應用請求值階段的目的是讓每一個組件檢索本身當前的狀態信息.與JSF中轉換器息息相關.

這些組件必須首先經過FacesContext對象進行檢索或建立(使用其值).雖然組件值也能夠從cookie或頭文件中進行檢索,可是它們一般是經過請求參數進行檢索的.

若是一個輸入組件的即時事件處理屬性immediate="true/false"沒有設置爲true,那麼就會對這些值進行轉換.所以，若是"域"被綁定到一個 Integer 屬性上,那麼該值就會被轉換爲一個Integer類型。若是值的轉換失敗了，那麼就會生成一個錯誤消息,並在 FacesContext 中進行排隊,在產生響應的階段會顯示其中的消息，同時還會顯示全部的驗證錯誤.

若是一個輸入組件的即時事件處理屬性immediate="true/false"被設置爲 true，那麼這些值就會被轉換爲適當的類型(注意:是轉換爲適當類型,也就是說不會去進行轉換的判斷!!!)，並進行有效性驗證。而後轉換後的值會被保存到組件中。若是值轉換或值的有效性驗證失敗了，就會生成一個錯誤消息，並在 FacesContext 中進行排隊，在產生響應的階段會顯示其中的消息，同時還會顯示全部的驗證錯誤。

第三階段:過程驗證+過程事件

生命週期中的第一個事件處理髮生在應用請求值階段以後。

在這個階段中,每一個組件都有一些值須要根據應用程序的驗證規則進行有效性驗證.這些驗證規則能夠是預先進行定義的（JSF 中提供的）,也能夠由開發者進行定義.

用戶所輸入的值會與這些驗證規則進行比較.若是說輸入的值無效，就會向 FacesContext 中添加一個錯誤消息，而且該組件會被表示爲無效的。

若是一個組件被表示爲無效的，那麼 JSF 就會轉到產生響應的階段，在這個階段中會顯示當前的視圖，以及驗證錯誤消息。

若是沒有有效性驗證錯誤，那麼 JSF 就會轉到更新模型值的階段。

若是在一個命令組件的及時處理屬性immediate="true/false"被設置爲 true，那麼"將也只會跳過這個表單"上的驗證過程.

第四階段:更新模型值+過程事件

這個階段負責更新服務器端模型的實際值.

一般來說,這都是經過更新後臺bean的屬性實現的.只有那些與組件值綁定在一塊兒的bean屬性纔會被更新.(其實就是backbean獲得屬性值了.....)

注意這個階段發生在有效性驗證以後,所以能夠確保拷貝到bean屬性的值都是有效的(至少在表單域一級都是有效的,在業務規則一級仍可能無效).

第五階段:調用應用程序+過程事件

在生命週期的這個階段JSF控制程序會調用程序來處理表單的提交操做.組件值已經通過了類型轉換和有效性驗證,並被應用到模型對象中了(其實就是後臺的backbean已經獲得了前臺的值,搞不清楚有些資料爲何總要說的很高深,- -!),所以您如今可使用它們來執行應用程序的業務邏輯了.

在這個階段,您還能夠爲一個給定的序列或不少可能的序列指定後面的邏輯視圖,這能夠經過爲一次成功的表單提交定義一個特定的結果並返回這個結果來實現。

例如：在成功輸出時，將用戶重定向到下一頁中。要讓這種導航工做可以起做用，您須要在faces-config.xml文件中建立一個到"成功輸出"的映射做爲一條導航規則。

一旦導航發生以後，您就轉換到生命週期的最後一個階段了.

第六階段:呈現響應

在視圖中顯示當前狀態中的全部組件

參照於網址https://my.oschina.net/zhaoqian/blog/71866