4GL開発者向けJava Server Faces（JSF）概要

4GL 開発者向け Java Server Faces（JSF）

概要

Oracle ホワイト・ペーパー

2006 年 11 月

4GL 開発者向け Java Server Faces（JSF）

概要

はじめに ... 4

JSF の概要 ... 4

JSF 開発の経緯... 4

JSF 以前 ... 5

コミュニティにおける JSF... 5

オラクルの貢献 ... 6

他社の貢献 ... 6

JSF の理解 ... 6

コンポーネントの概要... 6

コンポーネントのアーキテクチャ ... 7

コンポーネントのサポート ... 8

コンポーネントの簡単な例 ... 8

イベント・モデル... 10

Action イベント ... 10

Value change イベント... 10

Phase イベント... 11

ページ・フロー... 12

faces-config.xml の概要 ... 12

Action 属性 ... 13

マネージド・ビーン... 13

マネージド・ビーンの定義 ... 14

マネージド・ビーンの参照 ... 15

コンバータおよびバリデータ... 15

コンバータ ... 16

バリデータ ... 16

JSF ライフサイクル ... 16

概要... 16

フェーズの概要... 17

ビューのリストア ... 17

リクエスト値の適用 ... 17

プロセスのバリデーション ... 17

JSF の高度な機能 ... 18

スキニング... 18

レンダー・キット... 19

Ajax... 19

結論 ... 20

4GL 開発者向け Java Server Faces（JSF）

概要

はじめに

Java Server Faces（JSF）が、Java Web アプリケーションのユーザー・インタフェー ス（UI）レイヤーを構築するテクノロジとして、出現してきています。オラクル 独自のビジネス・アプリケーションは、"Fusion"スタックの UI テクノロジとして JSF をコミットしています。 IBM、BEA、Sun、および他社も、JSF を UI テクノロジとして使用することを表明 しました。 このコンポーネント・ベースのアーキテクチャによって、ビジネス開発者は、シ ンプルながらも強力な UI コンポーネントを用いてアプリケーションを構築でき るようになります。このアーキテクチャは、大規模な開発コミュニティが協力し て、より充実した高度なコンポーネントを構築できる標準的な方法を基盤にして います。 ここでは、4GL 開発者に JSF を説明し、コンポーネントの活用方法と、コンポー ネントが内部でどのように機能しているかについて解説します。

JSF の概要

Java Community Process（JCP）は、最初に Java Specification Request 127（JSR-127） として発表した JSF 標準を定義しており、その目的の 1 つを次のように述べてい ます。"・・・Java WebアプリケーションのGUIを作成するための標準APIを作

成することであり、それによって開発者がGUIインフラストラクチャを作成し維 持する負担を取り除くことができます。" これは、JSF が、ボタン、テキスト・フィールド、チェック・ボックスなどのウィ ジェットという、従来の UI でいうコンポーネントのようなものであることを意味 します。JSF は、先行する Web テクノロジである従来のマークアップ中心の方法 にとらわれません。つまり、ボタンはボタンであり、タグではないのです。ボタ ンには動作があり、ボタンが押され、押されて起こることをサポートするインフ ラストラクチャを確認できます。これは、Oracle Forms、Visual Basic、および PeopleTools で親しんできたものと同様です。

JSF 開発の経緯

2001 年の JSF 形成期から 2003 年の最初のリリース、そして 2006 年の現リリース （JSF 1.2 JSR-252）まで、JCP は JSF の仕様を定義し、その仕様のリファレンス 実装を作成するために、オラクルを含むコミュニティからリソースを集めてきま

JSF 以前

JSF に代表される、より単純な UI コンポーネント・ベースの触媒の役割を果たし た開発の経験なしに、JSF がどれだけ Java Web アプリケーション UI の水準を引 き上げてきたかを知るのは困難です。

静的HTML

Web の形成期において、静的な Hyper Text Markup Language(HTML)ページは、Web 上で見られる大量のコンテンツでできていました。最大の制約は、静的なページ では、データベースに保持される製品リストのようなあらゆる動的データの表示 が困難になることでした。また、一連の静的ページを単純に表示する以上のこと を行う場合は、キャリアとして HTTP の Post および Get メッセージを使用して、 サーバーを行き来する自身のコミュニケーションをコード化しなければなりませ んでした。 サーブレット 正確には、サーブレットによって HTML を生成する必要はありません。サーブ レットは、どんなマークアップ言語もエ ンド・ユーザー・デバイスに応じて生成 できます。例：携帯電話、PDA 静的ページの制約を克服するために、サーブレットが導入されました。結果とし て、Java プログラムが処理を行い、一連の HTML タグを出力することになりまし た。したがって、Web ページの開発では、開発者はブラウザによってレンダリン グされるタグを出力するプログラムをコード化する必要がありました。また、開 発者は、前に述べた Post および Get コミュニケーションも管理しなければなりま せんでした。

Java Server Pages

この Web ページ開発のプログラム的な方法から脱するため、次に発展したのが Java Server Pages（JSP）でした。ここでは、Web ページに埋込み可能な"特殊"なタ グがありました。これらのタグは JSP コンテナによって使用され、サーブレット、 さらにはマークアップが生成されました。そのため、JSP タグの開発者による概 念が存在し、JSTL（JSP 標準タグ・ライブラリ）経由でタグを使用できるさまざ まな開発者がいる場合もありました。 ただし、これは依然として UI 開発の"タグ"ベースの方法を意味しており、UI 開発 者は HTTP プロトコルの複雑さを理解し、ステートを管理する必要がありました。 こうして、JSF は最終的にイベント・モデルをサポートし、Oracle JDeveloper など の IDE を通したビジュアル編集を可能にするビジュアル・コントロールを用いて、 開発者が作業できる段階にまで Web UI の開発を進めたのです。

コミュニティにおける JSF

JSF は実証された標準であるため、誰もが使用目的で自分の JSF コンポーネント を開発でき、そのコンポーネントが動作する独自の JSF ランタイムを実装できま す。これは広いコミュニティで確認できます。

オラクルの貢献

オラクルは JSF 仕様に関わる主な専門的集団の 1 つであり、Oracle アプリケーショ ンの開発者が使用する独自の Web フレームワークから得た経験を提供しています。 それが、User Interface XML(UIX)です。仕様に関わった結果として、UIX コンポー ネントのライブラリが、標準 JSF コンポーネントとして再開発されました。この 一連のコンポーネントは ADF Faces と呼ばれ、JSF のどのようなランタイム実装 においても使用できます。 オープン・ソース・コミュニティにコミットされたため、オラクルは ADF Faces 実装も Apache コミュニティに提供し、これはこのコミュニティ内で Trinidad と呼 ばれています。

他社の貢献

JCP のメンバーである Sun は、JSF フレームワーク（JSF コンポーネントが動作す る環境）のリファレンス実装を提供し、これは現在、Java Enterprise Edition（EE） 5 に付属しています。 Apache コミュニティによる MyFaces は、1.1 リファレンス実装とコンポーネント・ ライブラリの両方を提供しています。ほかには、Java EE 5 アプリケーション・サー バーのオープン・ソース実装で、JSF 1.2 実装を含む Glassfish などが提供されてい ます。 重要なのは、コンポーネントが JSF 内で標準化されており、あらゆるベンダーの あらゆるコンポーネントを使用し、必要に応じてそれらを組み合わせることがで きるということです。

JSF の理解

次に、ADF Faces の一連のコンポーネント について考察します。全般的に、これは どのような JSF 実装にも適用できます。 _{コンポーネント・ベースのソリューションの必要性を理解したところで、次にこ} れらのコンポーネントと、提供される機能を確認します。

コンポーネントの概要

図 1 は、ADF Faces コンポーネントのサンプルを示したものです。アプリケーショ ンの各 Web ページは、コンポーネントで構成されます。通常、コンポーネントは、 他のコンポーネント（レイアウト・コンポーネントまたはレイアウト・コンテナ と呼ばれます）の中にネストされ、必要なレイアウトを提供します。

図 1 - ADF Faces コンポーネント

コンポーネントのアーキテクチャ

それぞれのコンポーネントは、3 つに代表されます。属性、ビヘイビア、および レンダラです。 属性 各コンポーネントには、そのコンポーネントに関連した多数の属性があります。 たとえば、ボタンにはボタン上に現れるテキスト・ラベルを定義する text 属性が あり、また、背景色を定義する backgroundcolor 属性などもあります。 ビヘイビア コンポーネントは、そのコンポーネントのビヘイビアを制御する多数のアクショ ンを定義します。たとえば、ボタンは、開発者がコードを関連付ける valueChange イベントを提供します。 レンダラ コンポーネントそのものには、上述の属性とビヘイビアが含まれますが、これら からはコンポーネントが実際にどのように見えるかはわかりません。これはレン ダラの役割となります。具体的な画面指示の定義どおりにコンポーネントを実現 するのはレンダラの役割です。たとえば、ブラウザ・アプリケーションの場合は、 HTML マークアップの断片となります。 JSF の UI コンポーネントは、マークアッ プの生成だけに留まりません。たとえば、 UI コンポーネントは、イメージ・ストリー ムなどのバイナリ・データや、SVG、PDF、 Word などの異なるドキュメント・タイプ もレンダリングできます。 別の（またはプラガブルな）レンダリングがあるということが、JSF の最も魅力的 な機能の 1 つです。コンポーネントのビヘイビアが、表示される方法と切り離さ れているということは、同じ UI コンポーネントを異なる方法で表示できることを 意味します。たとえば、レンダリング先のデバイス次第で異なることになります。

コンポーネントのサポート

ただし、コンポーネントは単独では機能しません。JSF ランタイムが、コンポー ネントをサポートする多数の機能を提供しています。 マネージド・ビーン マネージド・ビーンは、UI コンポーネントとコンポーネントが表示しているデー タ・オブジェクトとの間の統合を提供する Java オブジェクトです。このオブジェ クトの有効範囲は、Web ページをリクエストする際、またはセッションが多数の Web ページにわたる場合にのみ、オブジェクトがアプリケーションのライフタイ ムに存在するよう指示することで定義できます。 式言語 式言語（EL）は、JSF ランタイムの一部のスクリプト言語で、データ、マネージ ド・ビーン、およびコンポーネントのさまざまなプロパティにアクセスするため の単純化された式を提供します。EL は、JSF の非常に強力な機能です。たとえば、 コンポーネント属性（required 属性など）は、バッキング・ビーンのデータの値に 応じて次のような EL 式で設定できます。 #{emp.MaritalStatus =='single'}

MaritalStatus の値が"single"の場合（そして式が true と評価する場合）、required 属性は true に設定されます。

Oracle ADF では、UI コンポーネントを基礎となるデータに結び付けるための言語 として EL を使用しています。 ナビゲーション・ケース JSF フレームワークを使用すると、開発者はページ間のナビゲーションを定義す る一連のルールを定義できます。デフォルトでは、これは faces-config.xml と呼ば れるファイル中で定義されますが、これについては後ほど説明します。 ライフサイクル JSF リクエスト処理ライフサイクル（通常は JSF ライフサイクルと呼ばれます） は、特定の JSF リクエストにおける処理のさまざまな段階を表します。JSF ライ フサイクルのある特定の時点において、固有のアクションが発生します。それは、 現在のステートを取得するコンポーネントであったり、コンポーネントをレンダ リングするものであったりします。

コンポーネントの簡単な例

それぞれの"部分"が全体の一部としてどのように作用しているかを理解するため に、Web ページ上の JSF テキスト・フィールド・コンポーネントの簡単な例を確 認します。

単純化するためにいくつかのタグを省略 しています。 図 2 - シンプルな例 JDeveloper ビジュアル・エディタでページのデザイン・ビューからコード・ビュー に変更する場合、JDeveloper によって作成されたソースを確認できます。ソース・ コードには、次の 2 つのタグがあります。 • <f:view> • <h:inputText> 最初のタグは、すべての UI コンポーネントが現れるトップレベルのコンテナです。 JSF では、ページの定義をコンポーネント・ツリーに保持しており（これは実行 時に操作できます）、<f:view>はこのコンポーネント・ツリーをカプセル化します。 <h:inputText>は、このツリー中の UI コンポーネントで、入力テキスト・フィール ドを表します。 JSF の実装は、JSP をキャリア・テクノ ロジとして使用するようになっています。 つまり、ページ定義は JSP ページであり、 JSF コンポーネントは JSP タグ・ライブ ラリとして表現されます。これは、従来 の HTML/JSP エディタおよび IDE が JSF ページの設計に使用できることを意味し ます。JSF 自体は、ページ定義のフォー マットに関する想定を行いません。 実装詳細の非表示

入力フィールドには true に設定される required プロパティがあり、value プロパ ティはマネージド・ビーン経由で EL 式によって解決されることに注意してくだ さい。ただし、コンポーネントがプロパティを実装する方法や、コンポーネント が実際にコンポーネント自身をレンダリングする方法の詳細はありません。 つまり、このコンポーネントは、ブラウザ内で表示する場合は HTML マークアッ プを使用してレンダリングを行い、モバイル機器上で表示する場合はワイヤレ ス・マークアップ言語（WML）を使用してレンダリングし、またマークアップと JavaScript（後述の Ajax を参照）のハイブリッドによって、レンダリングする可能 性もあります。 UI 制御の実装詳細が表示されない点が、ビジネス開発者にとっての JSF の魅力で す。コンポーネントは、ただ単に機能を公開するだけです（Visual Basic や Oracle Forms における UI コンポーネントと同様）。

イベント・モデル

次に、UI コンポーネントが、ボタンの押下やリストからの値の選択などの UI ア クションまたは UI イベントを開始し、対処する方法を検討します。 JSF では、3 種類のイベントをサポートするイベント・モデルを提供します。

Action イベント

アクション・イベントは、Oracle Forms の When-Button-Pressed トリガーに類似 しています。 Action イベントは、ボタンやリンクなどの JSF UI コンポーネントがクリックされ ると発生します。 図 3 は、入力フィールド、ボタン、および出力フィールドを含む簡単な JSF ペー ジを示したもので、文字列"hello"と連結した入力フィールドからのデータを表示 します。 図 3 - イベントの簡単な例 ボタンをダブルクリックすることで、 JDeveloper は自動的にコード用のプレー スホルダを作成します。また、JDeveloper は、バッキング・ビーンと、UI コンポー ネントの値を取得して設定するためのア クセッサ・メソッドも作成します。 このメソッドは文字列を返すことに注意 してください。この場合は null です。こ の文字列の重要性については、後述のナ ビゲーションの項で説明します。 JDeveloper を使用すると、メソッドを Action 属性に追加でき、次のコードが実行 されます（マネージド・ビーンに保持）。

public String buttonPressed_action() { // Add event code here...

String inputText = (String)getInputText1().getValue(); getOutputText1().setValue(inputText + " hello!");; return null; }

Value change イベント

入力テキスト・フィールドなどの入力 UI コンポーネントには、データを変更する 際にトリガーされる 2 つのイベントがあります。ValueChangeListener はフィール ドの値が変わると起動し、Validator はデータ・エントリを検証するために起動し ます。

再び、JDeveloper は、メソッドの名前とメソッドが置かれるマネージド・ビーン を定義する単純なダイアログを提供し、正しいメソッド・シグネチャを生成しま す（図 4）。 図 4 - valueChangeListener の作成

Phase イベント

Phase イベントは、JSF ライフサイクルの特定のインスタンスで実行し、バリデー ション・フェーズなどの段階において、ユーザー独自のコードを JSF ライフサイ クルに追加するか、または値フェーズでモデルを更新します。 これらのイベントにとって重要な点は、ユーザーがコード化できることではなく、 コード化する必要がないことです。 • HTTP リクエストを処理して、発生しているイベントをチェックする必要 がありません。 • HTTP リクエストを処理して、入力テキスト・フィールドに入力された値 を見つける必要がありません。 • 出力フィールドの値を設定する HTTP レスポンスの処理がありません。 これは、出力テキスト・フィールドで属性を設定して行われます。

JSF フレームワークは、アクションをコードに関連付ける"配管工事"に対応するた めの抽象化レイヤーを提供し、コンポーネントの属性にアクセスするためのコー ド化を行います。

ページ・フロー

ページ上のコンポーネントのフレームワークを定義するのと同様、JSF はアプリ ケーション・ページ間のフローを管理するフレームワークも定義します。つまり、 ページ上で特定のアクションを実行することによって、別の Web ページへナビ ゲートされることになります。

faces-config.xml の概要

faces-config.xml ファイルには、単なるナ ビゲーション・ルール以上の情報が含ま れていることに注意してください。JSF への導入として、このファイルに最初に 関わる際にナビゲーションが定義されま すが、これはマネージド・ビーン、レン ダー・キット、コンバータ、およびバリ データの指定にも使用されます。 JSF は、Web ページを通してアプリケーションのフローを処理し、開発者側のコー ディングは最低限で済みます。その代わりに、XML ファイルは、特定のページの どのアクションが別の特定のページへナビゲートすることになるのかを定義しま す。この XML ファイルは、faces-config.xml と呼ばれます。 図 5 は、browserCustomers ページにナビゲーション・ケースを持つ、faces-config.xml ファイルの例を示したものです。edit アクションは editCustomers ページへのナビ ゲーションへつながり、showOrders アクションは customerOrders Web ページへの ナビゲーションへつながります。

ただし、JDeveloper は、ページ・ナビゲーション・ルールを定義して視覚化する ビジュアル・エディタを提供することによって、このファイルの管理をより簡単 にします。 図 6 - Faces-config.xml

Action 属性

実際にアクションを発生させる UI コンポーネントを定義するには、コンポーネン ト上で action プロパティを設定します。これは、前述のボタンを押す際に実行さ れるメソッドを定義するプロパティと同じです。action プロパティは、ダイアグ ラム上のナビゲーション・ケースの名前、またはメソッドの名前を取ることがで きます。前述したアクション・メソッドが、後に続く JSF ナビゲーション・フロー の名前を定義する文字列を返すのはこのためです。

マネージド・ビーン

マネージド・ビーンの役割は、非常に単純です。マネージド・ビーンは、UI アク ション（押されるボタンなど）に関連するコードを置き、UI に関するステート情 報（ログオンしたユーザーの名前など）を保持しておく場所です。さらに具体的 にいえば、マネージド・ビーンには、通常、多数のページ間で共有されるコード が含まれます。

制御の反転(IoC)という用語は、マネージ ド・ビーンを説明する際にしばしば使用 されます。これは単に、オブジェクト（こ の場合はマネージド・ビーン）の管理が、 アプリケーション開発者ではなく、フ レームワークへ委ねられることを意味し ます。 マネージド・ビーンのライフサイクルは、JSF によって行われます。ビーンが最 初に参照されると、JSF は関連する Java クラスのインスタンスを作成し、ビーン 定義によって指定されている間それを維持します。 また、バッキング・ビーンの概念もあります。バッキング・ビーンは、JDeveloper が作成して管理する特殊なマネージド・ビーンで、1 つの特定の JSF ページに結 びついています。通常、このビーンは、それがバックアップするページ上の各 UI コンポーネントのアクセッサ・メソッドを提供します。 バッキング・ビーンは、すべてのページに必要なわけではありません。バッキング・ ビーンがまったくなくてもページは無事に動作し、バッキング・ビーンにはページ 上のいくつかのコンポーネントへの参照が含まれるだけの場合もあります。ほとん どの場合、バッキング・ビーンにはアクション・コードのみが含まれ、プログラム 的に操作する必要がある場合以外は、UI コンポーネントへの参照は含まれません。 前の例（図 3）では、バッキング・ビーンは、ページ上で作成されたコンポーネン トを参照し、アクション・コードを置く場所を提供するために使用されていました。

マネージド・ビーンの定義

マネージド・ビーンは、faces-config.xml ファイルで登録されます。ただし、 JDeveloper は、これらのビーンの作成および参照における支援を提供できます。JSF アプリケーションが起動すると、アプリケーションは faces-config.xml ファイルを 読み込んでビーンを利用可能にします。マネージド・ビーンには、多数の構成オ プションがあります。 マネージド・ビーンのプロパティ UI アクション・コードを置く場所と同様に、マネージド・ビーンにも変数を追加 できます（PL/SQL のパッケージ変数と同様）。1 つまたは多数の UI フィールド用 のデフォルト値として使用される値を定義する場合について考えてみます。これ は、プロパティのタイプや値を定義できるマネージド・プロパティを使用するこ とによって実現できます。そして、EL を使用してアクセスでき、フィールドの値 を移入します。faces-config.xml ファイルのエントリには、次のものが含まれます。 <managed-property> <property-name>defValue</property-name> <property-class>java.lang.String</property-class> <value>hello</value> </managed-property> そのプロパティは、次によって JSF からアクセスできます。 #{backing_page1.defValue} マネージド・ビーンのスコープ それぞれのマネージド・ビーンには、"ライフスパン"があります。JSF は自動的に ビーンをインスタンス化し、そのビーンは定義されたスコープに対して利用可能

• アプリケーション - ビーンは、Web アプリケーションの継続中に利用可 能です。これは、どのアプリケーションのグローバル・データに対して も有効です。 • セッション - ビーンは、クライアントのセッション継続中に利用可能で す。たとえば、ショッピング・カート・アプリケーションは、多数の Web ページ間のセッション情報を維持します。 • リクエスト - ビーンは、ビーンがインスタンス化された時点からレスポ ンスがクライアントに返されるまで利用可能です。たとえば、ボタンが 押された時点からクライアントがレスポンスを受け取るまでの間です。 • なし - ビーンは、参照されるたびにインスタンス化されます。

マネージド・ビーンの参照

マネージド・ビーン内の情報や機能を定義したので、その情報にアクセスできます。 ELからの参照 EL を使用することによって、マネージド・ビーンからマネージド・プロパティを 参照できます。

<af:inputText id="fieldA" value="#{backing_page1.defValue}"/>

このように、このフィールドを実現する際、フィールドの値は backing_page1 マ ネージド・ビーンの defValue マネージド・プロパティに設定されます。 Javaからの参照 Java からもマ ネージド・プ ロパティにア クセスできま す。このため には、 FacesContext のカレント・インスタンスを取得します。このオブジェクトには、JSF ライフサイクル内のコンポーネントについて、すべてのステート情報が含まれま す。FacesContext のカレント・インスタンスへのハンドルを取得することによって、 JSF ライフサイクルの要素へアクセスできます。 FacesContext fc = FacesContext.getCurrentInstance(); ValueBinding expr = fc.getApplication(). createValueBinding("#{backing_page1.defValue}"); System.out.println(expr.getValue(fc).toString());

コンバータおよびバリデータ

ユーザーがデータを JSF ページに入力し、そのページがブラウザからサブミット されると、ページ上のすべてのデータは、結果として生じる文字列などの HTTP メッセージの中に入れられます。したがって、入力されたデータが日付か数字か に関係なく、データが処理のためにアプリケーション・サーバーに到達すると、 データは文字列として現れます。

そのため、フレームワークを使用しない場合は、コードを書いて文字列を正しい データ型に変換する必要があります。 しかし、この機能は JSF を通して提供されます。

コンバータ

名前が示すとおり、コンバータは文字列データを java.util.Date や java.lang.Number などの型に変換します。JDeveloper では、コンバータのパレットを提供しており、 コンバータを合理的に必要とするコンポーネント用のコンバータを自動的に追加 します。たとえば、日付データにバインドされる入力フィールドなどです。した がって、日付を表し、HTTP 経由で文字列として送信される入力データは、引き 続き java.util.Date としてバックエンド・コードに入力できます。

バリデータ

一方、バリデーションは、データがモデル・レイヤーに更新される前に、ルール やコンディションに対して編集可能なコンポーネント・データが検証されるプロ セスです。したがって、ページにデータをポストする前に、たとえばデータが定 義された制限内にあることをチェックします（<af:validateDateTimeRange>）。コ ンバータの場合と同様、JDeveloper はバリデータのパレットを提供し、自動的に それらを特定の UI アイテム上に含みます。

JSF ライフサイクル

"JSF ライフサイクル"の用語については既に触れましたが、これが意味する内容を もう少し詳しく確認します。

概要

リクエストの処理が開始すると（ボタンを押した結果など）、JSF は一連の手順 を実行します。これらの手順は、ライフサイクルと呼ばれます。JSF ページのラ イフサイクルは、ほとんどの Web ページのライフサイクルに酷似しています。つ まり、クライアントが HTTP リクエストを行うと、アプリケーション・サーバー はリクエストを受信して処理し、HTML で応答します。ただし、JSF ライフサイ クルでは、サーバー上で UI コンポーネント・ツリーを管理し、イベントの制御お よびステート変更の処理も行います。 このホワイト・ペーパーでは説明しませ んが、JSF ライフサイクルは、特殊化し たビヘイビアを要求する場合、カスタマ イズできます。 JSF ライフサイクルでは、コンポーネント・ツリーを使用してアプリケーション のリクエストを処理し、レンダリングされたレスポンスを作成します。リクエス トとレスポンスのタイプによって、JSF はリクエスト処理ライフサイクルの異な るフェーズで異なるタスクを実行し、レンダリングのためのページのビュー（コ ンポーネント・ツリー）を作成します（レスポンスのレンダリング・フェーズ）。

図 7 - JSF ライフサイクル

フェーズの概要

各フェーズの詳細についてはこのホワイト・ペーパーの範囲外ですが、フェーズ の存在と機能の概要を確認しておくことは有益です。JSF ライフサイクルのフェー ズを、次に簡潔に説明します。

ビューのリストア

ページの内部ビューは、コンポーネント・ツリーに保持されます。このフェーズ では、ページのコンポーネント・ツリーが新しく構築またはリストアされます。 すべてのコンポーネント・タグ、イベント・ハンドラ、コンバータ、およびバリ データは、FacesContext インスタンスにアクセスできます。これが新しい空のツ リーの場合、ライフサイクルはレスポンスのレンダリング・フェーズに直接進み ます。

リクエスト値の適用

ツリーの各コンポーネントは、その新規の値をリクエスト・メッセージから抽出 し、ローカルで保存します。コンポーネントに true と設定される immediate 属性 がある場合、そのコンポーネントに関連するバリデーション、変換、およびイベ ントは、このフェーズの間に処理されます。

プロセスのバリデーション

コンポーネントのローカル値が変換され、検証されます。エラーが発生した場合、 ライフサイクルはレスポンスのレンダリング・フェーズへ移動します。このフェー ズの最後では、新規のコンポーネント値が設定され、すべての変換エラーメッセー ジおよびイベントが FacesContext のキューに追加されます。 モデル値の更新 コンポーネント・オブジェクトのプロパティが、検証されたローカル値に設定さ れます。 アプリケーションの起動

レスポンスのレンダリング ツリー内のコンポーネントは、Web コンテナがページ内のタグを横断する際にレ ンダリングされます。ステート情報は、次に続くリクエストとビューのリストア・ フェーズ用に保存されます。

JSF の高度な機能

このホワイト・ペーパーは概要を説明するものなので、高度な機能についてはそ の範囲を超えています。しかし、それらの機能の基本について確認しておくこと は有益です。

スキニング

スキニングは、アプリケーション UI に全体的な"ルック・アンド・フィール"を定 義する機能です。Windows でデスクトップにテーマを定義できるのと同じ方法で、 ADF Faces では、JSF のプラガブルなレンダリング・テクノロジを使用することに よってこの機能を提供しています。 図 8 - スキニング 図 8 は、異なるスキンを使用してレンダリングされた同一のアプリケーションを 示したものです。ADF Faces は、事前に設定された多数のスキンを備えています が、カスケーディング・スタイル・シート（CSS）タグを操作することによって、

レンダー・キット

JSF コンポーネントは、それぞれ、スクリーンを物理的にレンダリングするエン ド・デバイスによって使用される、独自のマークアップ・タグの出力を行います。 ADF Faces では、HTML、モバイル、および Telnet 対応のレンダー・キットを提供 しています。 図 9 - レンダー・キット 図 9 は、異なるレンダー・キットを使用してレンダリングされたアプリケーショ ンの例を示しています。JSF でも、独自のレンダー・キットを作成できます。

Ajax

Web UI は、"クリックして待つ"パラダイムで動作します。つまり、リクエストは UI アクション（ボタンのクリックなど）によってのみ始動し、UI はレスポンスを 待ちます。これは、充実したエクスペリエンスが作り出されるのを妨げる要因と なり得ます。この理由から、いわゆる Ajax テクノロジが登場しました。 Ajax は、非同期な JavaScript と XML に基づいています。ブラウザは、XML デー タを非同期に要求するための機能をサポートしています。したがって、XML デー タの非同期的な通過とブラウザ上の JavaScript の組合せによって、非常に充実した Web UI が生成されることになります。 4GL 開発者にとってのこのテクノロジの魅力は、Ajax の機能を JSF コンポーネン トの中に隠せる点にあります。

ADF Faces コンポーネントの中には、すでに"Ajax のような"動作を示すものもあ りますが、このホワイト・ペーパーの執筆時点では、ADF Faces コンポーネント 内の真の Ajax 機能は開発途中にあります。

結論

Java Server Faces は、機能が豊富で生産性の高い標準ベースのフレームワークを Web UI 開発者に提供しています。Java Server Faces は、コンポーネント化された 抽象化レイヤーを提供することによって、特に Oracle Forms、PeopleTools、Visual Basic などの 4GL ツールに慣れている開発者を、Web UI 開発の複雑さから多くの 面で解放します。

4GL 開発者向け Java Server Faces（JSF）概要 2006 年 11 月 著者: Grant Ronald Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. お問合せ: 電話: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com

Copyright © 2006, Oracle.All rights reserved.

本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更さ れることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、 口述による明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合 性についての黙示的な保証を含み、いかなる他の保証や条件も提供するものではありませ ん。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本文書によって直接 的または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面に