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

- 復元ビューの作成
- JavaServer Faces コンポーネント・ツリーは、ページの状態とイベントの作成と維持に使用されます。
このツリーはセッションごとに 1 回作成され、ユーザーがページに戻る時点で再使用されます。
このフェーズの終わりには、FacesContext インスタンスの、現在の要求の root プロパティーには、前の
Faces Response により生成されたビューの保管構成があれば、これが反映されます。
- 要求値の適用
- 要求処理ライフ・サイクルのこのフェーズの目的は、現在の要求の中に含まれている、パラメーター、ヘッダー、Cookie
などの情報を使用して、それぞれのコンポーネントにその現行値を更新する機会を与えることにあります。
- プロセス妥当性検査
- この要求のビューの作成の一環として、
ゼロまたはそれ以上のバリデーター・インスタンスをコンポーネントごとに登録することができます。
さらに、コンポーネント・クラス自体は、その validate() メソッドの中に妥当性検査論理を実装することができます。
このフェーズの終わりには、すべての構成済み妥当性検査が完了します。
妥当性検査が失敗すると、現在の要求に対する FacesContext インスタンスの
addMessage() メソッドの呼び出しを介してメッセージがエンキューされ、
対応するコンポーネントに関する有効なプロパティーが偽に設定されます。
呼び出された validate() メソッドのどれかが現在の要求の FacesContext インスタンス上の
responseComplete() を呼び出した場合は、現在の要求のライフ・サイクル処理をただちに終了させる必要があります。
呼び出された validate() メソッドのどれかが現在の要求の FacesContext インスタンス上の
renderResponse() を呼び出した場合は、要求処理ライフ・サイクルの応答フェーズに制御を移す必要があります。
同じ条件は、待機イベントを処理したイベント・リスナーにもあてはまります。
以上の条件がどれも発生しない場合は、モデル値を更新するために制御は次のフェーズに進みます。
- モデル値の更新
- 要求処理ライフ・サイクルのこのフェーズに達した場合は、入来の要求が行われた妥当性検査では構文上でも意味構造上でも正しく、
コンポーネント・ツリーの中のどのコンポーネントのローカル値も更新されており、
待機していたアプリケーション・イベントを実行する準備が整い、
現在はアプリケーションのモデル・データの更新に適切な状態になっています。
- アプリケーションの呼び出し
- 復元ビューの作成のフェーズに説明されているように、
現在の要求に対するビューが前の要求により保管された状態情報から再構成されている場合は、
この Web アプリケーションのアプリケーション・オブジェクトに基づく getActionListener
の呼び出しによって戻された ActionListener が登録されることを JavaServer Faces 実装が保証していることになります。
ここでは、restoreState() メソッドに従ってコンポーネント・ツリーの中の全 UICommand コンポーネントも一緒に登録されます。
- 応答のレンダリング (応答の生成)
- このフェーズでは、同時に 2 つのことが達成されます。その 1 つは、応答をクライアントにレンダリングすることであり、もう
1 つは応答の状態を後続の要求に基づく処理に備えて保管しておくことです。
1 つのフェーズにおいて上記の責任範囲を両方とも扱うという理由は、JSP アプリケーションの中で応答をレンダリングすることにより、
ビューをページ・レンダーとして作成することができるからです。
したがって、応答がクライアントにレンダリングされるまでは、ビューの状態を保管することはできません。
- イベント処理
- 要求処理ライフ・サイクルの幾つかのフェーズでは、たとえば、ソース UIComponent インスタンスに基づく
queueEvent() メソッドの呼び出しまたは FacesEvent インスタンスに基づく
queue() メソッドの呼び出しを介して、イベントを待機させることができます。
ここで、この待機しているイベントを関係するイベント・リスナー向けにブロードキャストする必要があります。このブロードキャストは、
該当ライフ・サイクル管理メソッド (processDecodes()、processValidators()、processUpdates()、または processApplication())
の呼び出しの副次作用として行われます。この呼び出しは、現在のコンポーネント・ツリーのルートにある
UIViewRoot インスタンスに基づくものです。
それぞれの待機イベントごとに、全イベント・リスナー向けにイベントのブロードキャストを行うために、
ソース UIComponent の broadcast() メソッドが呼び出されます。このリスナーは、
このソース・コンポーネント上に、指定されたタイプのイベントのインタレストを登録しています。
このイベントが完全に処理されているかどうか、JavaServer Faces
実装でイベント・キューからイベントが除去できるかどうかを示す boolean のフラグが戻されます。
イベント・リスナーには、要求処理ライフ・サイクルの現在のフェーズにおいて追加イベントをキューに入れることも可能です。
このようなイベントは、キューに入れられた順序でブロードキャストを行う必要がありますが、
これを行うのはキューに入れられた元の全イベントのブロードキャストが行われた後で、
しかもライフ・サイクル管理メソッドが戻される前でなくてはなりません。
詳細な機能要件については、UIComponent.broadcast() メソッドの API 参照を参照してください。