這是jsf 的分析系列第三篇，隨著不斷的深入，jsf的設計變得越來越清晰。當然，在目前的規范中，jsf還是很不完善的，這也就導致了為什么jsf還是不能成為目前的主流框架。先不去談論這些弊端，還是先看看一下jsf具體是如何運作的。
對于jsf規范，個人覺得和其他框架相比，最大的區別，可能在于jsf劃分了web 請求的生命周期。like ejb一樣，web 請求也是有生命周期的。雖然，在其他的框架中，也可以看到相關的生命周期，但還是沒有jsf劃分的清晰。也許，這也是jsf的一大特色。
對于生命周期的執行，所有的操作都歸結到Lifecycle這個接口。接口包括了兩個主要的方法：
public abstract void execute(FacesContext context) throws FacesException;和
public abstract void render(FacesContext context) throws FacesException;
前者是用來執行各個生命周期的階段，也就是除了render之外的其他五個階段，而且是按照相應的順序執行。而render，是執行最后一個階段，展示頁面。可能有人不太理解，為什么不把兩個方法合并成一個方法，剛開始，我也是這么認為。既然已經定義了相應的Phase，何必要把最后的render過程分離出來。看了sun 的RI實現類，發現在render之前需要進行context.getResponseComplete()判斷，可能規范中，認為render是必須要執行的階段，其他的階段可以跳過，所以分離了相應的方法,同時在執行前,為了避免重復輸出,需要對render過程進行特殊的處理.
規范中定義了6個階段，從下面的流程圖中可以看到。
簡單介紹一下每個階段的工作：
RESTORE_VIEW：查找原有的view ，恢復原有的狀態，如果沒有，則調用ViewHandler.createView，如果為post操作，則按照順序執行各個階段。
否則執行RENDER_RESPONSE階段。
APPLY_REQUEST_VALUES：讀取客戶端參數，處理各個組件的processDecodes方法，內部調用decode方法，由Renderer執行decode方法
PROCESS_VALIDATIONS：執行組件的processValidators方法，對于UIInput執行validate方法，用于綁定值，調用convert,和validate
UPDATE_MODEL_VALUES:執行組件的processUpdates方法，對于UIViewRoot，執行broadcastEvents和notifyPhaseListeners
所有的UIInput,執行updateModel方法。
INVOKE_APPLICATION：調用UIViewRoot.processApplication方法。這一過程主要讀取相應的action配置，如果存在action，則調用action，也就是調用應用邏輯。在執行完相應的邏輯后，查詢action是否返回值，如果有，由navigationHandler去讀取下一個view id。
RENDER_RESPONSE：展示view，調用ViewHandler.renderView,展示view。
每個階段定義定義的都比較清晰，有一點需要注意的是，在處理請求時，并不一定會執行每個階段，可能其中會直接跳到最后的render response階段。舉例來說，如果validator時，存在錯誤信息，那么就會直接到render response階段，而下一個階段不會執行。
posted on 2007-05-04 15:44
布衣郎 閱讀(3537)
評論(3) 編輯 收藏 所屬分類:
web view技術