ADF生命週期階段差異

ADF initContext和prepareModel之間的區別，因爲它們都通過執行buisness服務來準備數據，通過綁定容器（Map對象）來實現。ADF生命週期階段差異

來源

2012-07-26 user530158

ADF和調用initContext prepareModel，因爲兩者均是通過執行樓內設有商務服務

這是不太正確的準備數據。 initContext設置了BindingContext，它確保DataBindings.cpx的內容被初始化，並且準備頁面的綁定容器。 prepareModel是數據查詢的執行點。

另一個執行點，如Timo's answer所示，是PrepareRender。建議儘量保持迭代器的默認設置，這是「延遲」，在這種情況下，只有那些迭代器被刷新並被查詢具有UI依賴性。

來源

2012-07-27 06:09:38

這是否意味着在prepareRender階段還會執行buisness服務，即組件被更新爲其partialTrigger設置在其他組件上的組件。 – user530158 2012-07-31 06:23:55

實際上階段是準備渲染：http://docs.oracle.com/cd/E15051_01/web.1111/b31974/adf_lifecycle.htm它是在準備渲染之前調用的。在ADF中，您有兩個常用的刷新鉤子：準備模型並準備渲染。默認設置是「延遲」。這裏的刷新是針對從UI組件引用的那些綁定的呈現響應。刷新可能不會重新執行數據庫中的查詢，但最初會刷新ADF中保存的迭代器。如果數據需要通過查詢，那麼這是當它發生 – 2012-08-03 05:32:56

謝謝弗蘭克，評論真正有助於理解ADF的生命週期。 – user530158 2012-11-27 05:41:26

ADF模型生命週期階段：

調用initContext樹立生命週期，工作出了什麼PageDefs加載。
prepareModel創建綁定對象並將其添加到HTTP請求中。此時也評估參數。
applyInputValues處理從頁面發佈的值，並建立一個內部綁定列表來更新，並根據需要執行方法。
validateInputValues將客戶端驗證程序應用於applyInputValues階段提供的更新列表。這些驗證器被定義爲輸入組件內嵌套的f：validator和af：convertNumber組件。
processUpdateModel將已驗證的更改發送到綁定對象到模型圖層。
validateModelUpdates管理來自Model層的驗證錯誤。
processComponentEvents處理從applyInputValues階段排隊的所有偵聽器和動作事件。
metadataCommit管理框架的運行時定製功能的一部分。如果用戶以某種方式定製了頁面，例如在屏幕上移動組件或通過WebCenter添加任務流，那麼屏幕上的這些個性化設置將被保存此時轉移到元數據存儲庫（MDS）。
prepareRender是在頁面顯示前執行的最後階段。

注意，在某些情況下（如一個模態對話框），下面的代碼不一定會在頁面已經被渲染後火：

public void afterPhase(PagePhaseEvent pagePhaseEvent) { 
    if (pagePhaseEvent.getPhaseId() == Lifecycle.PREPARE_RENDER_ID) { 
     injectRedirect(); 
    } 
    }

這可以防止服務器代碼能夠檢查在文件被渲染後立即使用af：document。例如，下面將失敗，因爲沒有可用的文檔：

return context.getViewRoot().getChildren().get(0).getClientId().equals("doc0");

來源

2012-07-26 11:53:36

ADF生命週期階段差異

回答

相關問題