JavaServer Faces のライフサイクル

JavaServer Pages (JSP) ページをレンダリングする各 JavaServer Faces 要求には、ビューとも呼ばれる JavaServer Faces コンポーネント・ツリーが含まれ、複数のフェーズからなる要求処理のライフサイクルの中を進んでいきます。 要求処理ライフサイクルの標準フェーズは復元ビューの作成で始まり、次に要求値の適用、 妥当性検査の処理、モデル値の更新、そしてアプリケーションの呼び出しへと続いていきます。

JavaServer Faces のライフサイクルを示すダイアグラム
復元ビューの作成
JavaServer Faces コンポーネント・ツリーは、ページの状態とイベントの作成および維持に使用されます。 このツリーはセッションごとに 1 回作成され、ユーザーがそのページに戻ると再使用されます。 前の Faces Response で生成されたビューの保存構成がある場合、このフェーズの終わりで、現在の要求の FacesContext インスタンスの root プロパティーにこれが反映されます。
要求値の適用
要求処理ライフサイクルのこのフェーズの目的は、現在の要求の中に含まれている、パラメーター、ヘッダー、Cookie などの情報を使用して、それぞれのコンポーネントにその現行値を更新する機会を与えることにあります。
妥当性検査の処理
この要求のビューの作成の一環として、ゼロまたはそれ以上のバリデーター・インスタンスをコンポーネントごとに登録することができます。 また、コンポーネント・クラス自体は、その validate() メソッドの中に検査ロジックを実装することができます。 このフェーズの終わりには、すべての構成済み妥当性検査が完了します。

検証が失敗すると、現在の要求の FacesContext インスタンスの addMessage() メソッドが呼び出されてメッセージがエンキューされ、対応するコンポーネントの有効なプロパティーが false に設定されます。 呼び出された validate() メソッドのいずれかが現在の要求の FacesContext インスタンスにある responseComplete() を呼び出した場合は、現在の要求のライフサイクル処理を直ちに終了させる必要があります。 呼び出された validate() メソッドのいずれかが現在の要求の FacesContext インスタンスにある renderResponse() を呼び出した場合は、要求処理ライフサイクルの応答のレンダリング・フェーズに制御を移す必要があります。 待機イベントを処理したイベント・リスナーにも、同じ条件が当てはまります。 以上のどの条件も発生しなかった場合は、次のフェーズに制御が移り、モデル値の更新が実行されます。

モデル値の更新
要求処理ライフサイクルのこのフェーズに入ったということは、妥当性検査を実行した結果、構文的にも意味的にも着信要求は有効であるということになり、コンポーネント・ツリー内のすべてのコンポーネントのローカル値が更新されて、待機していたアプリケーション・イベントの実行に向けて、アプリケーションのモデル・データが更新できる状態になったということになります。
アプリケーションの呼び出し
復元ビューの作成のフェーズに説明したとおり、現在の要求のビューが以前の要求で保存された状態情報から再構成されたものである場合、JavaServer Faces の実装では、この Web アプリケーションの Application オブジェクトにある getActionListener を呼び出すことによって戻された ActionListener が、restoreState() メソッドによってコンポーネント・ツリー内のすべての UICommand コンポーネントに登録されることになります。
応答のレンダリング
このフェーズでは、同時に 2 つのことが実行されます。つまり、応答をクライアントにレンダリングすること、および後続の要求での処理に備えて応答の状態を保存しておくことです。 これらの操作を 1 つのフェーズで同時に処理する理由は、JSP アプリケーションで応答をレンダリングする際に、ページ・レンダーとしてビューが作成されることがあるためです。 したがって、応答がクライアントにレンダリングされるまでは、ビューの状態を保存することはできません。
イベントの処理
要求処理ライフサイクルのいくつかのフェーズでは、例えば、ソース UIComponent インスタンスの queueEvent() メソッドの呼び出しや FacesEvent インスタンスの queue() メソッドの呼び出しなどによって、イベントがキューに入れられることがあります。 ここで、これらの待機イベントを関係するイベント・リスナーにブロードキャストする必要があります。 このブロードキャストは、現在のコンポーネント・ツリーのルートにある UIViewRoot インスタンスの該当ライフサイクル管理メソッド (processDecodes()、processValidators()、processUpdates()、または processApplication()) の呼び出しにおける副次作用として実行されます。 それぞれの待機イベントごとに、このソース・コンポーネントに関して指定タイプのイベントに対するインタレストを登録済みのすべてのイベント・リスナーに対して、ソース UIComponent の broadcast() メソッドが呼び出され、イベントがブロードキャストされます。 このイベントが完全に処理されているかどうか、JavaServer Faces 実装でイベント・キューからそのイベントを削除できるかどうかを示す boolean のフラグが戻されます。

イベント・リスナーはまた、要求処理ライフサイクルの現在のフェーズにおいて、追加イベントを処理するためにそのイベントをキューに入れることもできます。 このようなイベントは、初めに待機していたすべてのイベントのブロードキャストが行われた後で、 なおかつライフサイクル管理メソッドが戻される前に、キューに入れられた順にブロードキャストする必要があります。

詳細な機能要件については、UIComponent.broadcast() メソッドの API 参照を参照してください。


フィードバック