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

Transcription

1 4GL 開発者向け Java Server Faces(JSF) 概要 Oracle ホワイト ペーパー 2006 年 11 月

2 4GL 開発者向け Java Server Faces(JSF) 概要 はじめに... 4 JSF の概要... 4 JSF 開発の経緯... 4 JSF 以前... 5 コミュニティにおける JSF... 5 オラクルの貢献... 6 他社の貢献... 6 JSF の理解... 6 コンポーネントの概要... 6 コンポーネントのアーキテクチャ... 7 コンポーネントのサポート... 8 コンポーネントの簡単な例... 8 イベント モデル Action イベント Value change イベント Phase イベント ページ フロー faces-config.xml の概要 Action 属性 マネージド ビーン マネージド ビーンの定義 マネージド ビーンの参照 コンバータおよびバリデータ コンバータ バリデータ JSF ライフサイクル 概要 フェーズの概要 ビューのリストア リクエスト値の適用 プロセスのバリデーション JSF の高度な機能 スキニング レンダー キット GL 開発者向け Java Server Faces(JSF) 概要 2

3 Ajax 結論 GL 開発者向け Java Server Faces(JSF) 概要 3

4 4GL 開発者向け Java Server Faces(JSF) 概要 はじめに IBM BEA Sun および他社も JSF を UI テクノロジとして使用することを表明しました Java Server Faces(JSF) が Java Web アプリケーションのユーザー インタフェース (UI) レイヤーを構築するテクノロジとして 出現してきています オラクル独自のビジネス アプリケーションは "Fusion" スタックの UI テクノロジとして JSF をコミットしています このコンポーネント ベースのアーキテクチャによって ビジネス開発者は シンプルながらも強力な 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 の仕様を定義し その仕様のリファレンス実装を作成するために オラクルを含むコミュニティからリソースを集めてきました 4GL 開発者向け Java Server Faces(JSF) 概要 4

5 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 ランタイムを実装できます これは広いコミュニティで確認できます 4GL 開発者向け Java Server Faces(JSF) 概要 5

6 オラクルの貢献オラクルは 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 内で標準化されており あらゆるベンダーのあらゆるコンポーネントを使用し 必要に応じてそれらを組み合わせることができるということです 次に ADF Faces の一連のコンポーネントについて考察します 全般的に これはどのような JSF 実装にも適用できます JSF の理解 コンポーネント ベースのソリューションの必要性を理解したところで 次にこれらのコンポーネントと 提供される機能を確認します コンポーネントの概要図 1 は ADF Faces コンポーネントのサンプルを示したものです アプリケーションの各 Web ページは コンポーネントで構成されます 通常 コンポーネントは 他のコンポーネント ( レイアウト コンポーネントまたはレイアウト コンテナと呼ばれます ) の中にネストされ 必要なレイアウトを提供します 4GL 開発者向け Java Server Faces(JSF) 概要 6

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

8 コンポーネントのサポート ただし コンポーネントは単独では機能しません 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 テキスト フィールド コンポーネントの簡単な例を確認します 4GL 開発者向け Java Server Faces(JSF) 概要 8

9 単純化するためにいくつかのタグを省略しています 図 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 コンポーネントと同様 ) 4GL 開発者向け Java Server Faces(JSF) 概要 9

10 イベント モデル次に UI コンポーネントが ボタンの押下やリストからの値の選択などの UI アクションまたは UI イベントを開始し 対処する方法を検討します JSF では 3 種類のイベントをサポートするイベント モデルを提供します Action イベント アクション イベントは Oracle Forms の When-Button-Pressed トリガーに類似しています Action イベントは ボタンやリンクなどの JSF UI コンポーネントがクリックされると発生します 図 3 は 入力フィールド ボタン および出力フィールドを含む簡単な JSF ページを示したもので 文字列 "hello" と連結した入力フィールドからのデータを表示します 図 3 - イベントの簡単な例 ボタンをダブルクリックすることで JDeveloper は自動的にコード用のプレースホルダを作成します また JDeveloper は バッキング ビーンと UI コンポーネントの値を取得して設定するためのアクセッサ メソッドも作成します JDeveloper を使用すると メソッドを Action 属性に追加でき 次のコードが実行されます ( マネージド ビーンに保持 ) public String buttonpressed_action() { // Add event code here... このメソッドは文字列を返すことに注意してください この場合は null です この文字列の重要性については 後述のナビゲーションの項で説明します } String inputtext = (String)getInputText1().getValue(); getoutputtext1().setvalue(inputtext + " hello!");; return null; Value change イベント入力テキスト フィールドなどの入力 UI コンポーネントには データを変更する際にトリガーされる 2 つのイベントがあります ValueChangeListener はフィールドの値が変わると起動し Validator はデータ エントリを検証するために起動します 4GL 開発者向け Java Server Faces(JSF) 概要 10

11 再び JDeveloper は メソッドの名前とメソッドが置かれるマネージド ビーン を定義する単純なダイアログを提供し 正しいメソッド シグネチャを生成します ( 図 4) 図 4 - valuechangelistener の作成 Phase イベント Phase イベントは JSF ライフサイクルの特定のインスタンスで実行し バリデーション フェーズなどの段階において ユーザー独自のコードを JSF ライフサイクルに追加するか または値フェーズでモデルを更新します これらのイベントにとって重要な点は ユーザーがコード化できることではなく コード化する必要がないことです HTTP リクエストを処理して 発生しているイベントをチェックする必要がありません HTTP リクエストを処理して 入力テキスト フィールドに入力された値を見つける必要がありません 出力フィールドの値を設定する HTTP レスポンスの処理がありません これは 出力テキスト フィールドで属性を設定して行われます 4GL 開発者向け Java Server Faces(JSF) 概要 11

12 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 ページへのナビゲーションへつながります 図 5 - Faces-config.xml 4GL 開発者向け Java Server Faces(JSF) 概要 12

13 ただし JDeveloper は ページ ナビゲーション ルールを定義して視覚化する ビジュアル エディタを提供することによって このファイルの管理をより簡単にします 図 6 - Faces-config.xml Action 属性実際にアクションを発生させる UI コンポーネントを定義するには コンポーネント上で action プロパティを設定します これは 前述のボタンを押す際に実行されるメソッドを定義するプロパティと同じです action プロパティは ダイアグラム上のナビゲーション ケースの名前 またはメソッドの名前を取ることができます 前述したアクション メソッドが 後に続く JSF ナビゲーション フローの名前を定義する文字列を返すのはこのためです マネージド ビーンマネージド ビーンの役割は 非常に単純です マネージド ビーンは UI アクション ( 押されるボタンなど ) に関連するコードを置き UI に関するステート情報 ( ログオンしたユーザーの名前など ) を保持しておく場所です さらに具体的にいえば マネージド ビーンには 通常 多数のページ間で共有されるコードが含まれます 4GL 開発者向け Java Server Faces(JSF) 概要 13

14 制御の反転 (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 は自動的にビーンをインスタンス化し そのビーンは定義されたスコープに対して利用可能となります マネージド ビーンのスコープは faces-config.xml ファイルで設定されます 次の 4 つの可能性があります 4GL 開発者向け Java Server Faces(JSF) 概要 14

15 アプリケーション - ビーンは 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 メッセージの中に入れられます したがって 入力されたデータが日付か数字かに関係なく データが処理のためにアプリケーション サーバーに到達すると データは文字列として現れます ここで困難なのは " バックエンド " コードを構築している開発者は 通常 Java 型 (Integer や Date など ) を使用してそのデータを操作するという点です 4GL 開発者向け Java Server Faces(JSF) 概要 15

16 そのため フレームワークを使用しない場合は コードを書いて文字列を正しいデータ型に変換する必要があります しかし この機能は 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 はリクエスト処理ライフサイクルの異なるフェーズで異なるタスクを実行し レンダリングのためのページのビュー ( コンポーネント ツリー ) を作成します ( レスポンスのレンダリング フェーズ ) 4GL 開発者向け Java Server Faces(JSF) 概要 16

17 図 7 - JSF ライフサイクル フェーズの概要各フェーズの詳細についてはこのホワイト ペーパーの範囲外ですが フェーズの存在と機能の概要を確認しておくことは有益です JSF ライフサイクルのフェーズを 次に簡潔に説明します ビューのリストアページの内部ビューは コンポーネント ツリーに保持されます このフェーズでは ページのコンポーネント ツリーが新しく構築またはリストアされます すべてのコンポーネント タグ イベント ハンドラ コンバータ およびバリデータは FacesContext インスタンスにアクセスできます これが新しい空のツリーの場合 ライフサイクルはレスポンスのレンダリング フェーズに直接進みます リクエスト値の適用ツリーの各コンポーネントは その新規の値をリクエスト メッセージから抽出し ローカルで保存します コンポーネントに true と設定される immediate 属性がある場合 そのコンポーネントに関連するバリデーション 変換 およびイベントは このフェーズの間に処理されます プロセスのバリデーションコンポーネントのローカル値が変換され 検証されます エラーが発生した場合 ライフサイクルはレスポンスのレンダリング フェーズへ移動します このフェーズの最後では 新規のコンポーネント値が設定され すべての変換エラーメッセージおよびイベントが FacesContext のキューに追加されます モデル値の更新 コンポーネント オブジェクトのプロパティが 検証されたローカル値に設定されます アプリケーションの起動 アクション イベントなどのアプリケーション レベル コードが実行されます 4GL 開発者向け Java Server Faces(JSF) 概要 17

18 レスポンスのレンダリングツリー内のコンポーネントは Web コンテナがページ内のタグを横断する際にレンダリングされます ステート情報は 次に続くリクエストとビューのリストア フェーズ用に保存されます JSF の高度な機能 このホワイト ペーパーは概要を説明するものなので 高度な機能についてはその範囲を超えています しかし それらの機能の基本について確認しておくことは有益です スキニングスキニングは アプリケーション UI に全体的な " ルック アンド フィール " を定義する機能です Windows でデスクトップにテーマを定義できるのと同じ方法で ADF Faces では JSF のプラガブルなレンダリング テクノロジを使用することによってこの機能を提供しています 図 8 - スキニング 図 8 は 異なるスキンを使用してレンダリングされた同一のアプリケーションを示したものです ADF Faces は 事前に設定された多数のスキンを備えていますが カスケーディング スタイル シート (CSS) タグを操作することによって 独自のカスタム スキンを作成できます 4GL 開発者向け Java Server Faces(JSF) 概要 18

19 レンダー キット 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 コンポーネントの中に隠せる点にあります 4GL 開発者向け Java Server Faces(JSF) 概要 19

20 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) 概要 20

21 4GL 開発者向け Java Server Faces(JSF) 概要 2006 年 11 月著者 : Grant Ronald Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. お問合せ : 電話 : Fax: oracle.com Copyright 2006, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されており ここに記載される内容は予告なく変更されることがあります 本文書は一切間違いがないことを保証するものではなく さらに 口述による明示または法律による黙示を問わず 特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み いかなる他の保証や条件も提供するものではありません オラクル社は本文書に関するいかなる法的責任も明確に否認し 本文書によって直接的または間接的に確立される契約義務はないものとします 本文書はオラクル社の書面による許可を前もって得ることなく いかなる目的のためにも 電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません Oracle JD Edwards PeopleSoft および Siebel は オラクル社およびその子会社 関連会社の登録商標です その他の名称はそれぞれの会社の商標です