Oracle ADF UIX開発者ガイド | ![]() 目次 |
![]() 前へ |
![]() 次へ |
ここでは、次の項目について説明します。
通常、Webページでは、フォーム・データの入力や送信、別のページへのナビゲートなどの様々な処理がサポートされています。 この他に、多くのWebページでは、ユーザーが実際に別のページへナビゲートせずにWebページ自体のコンテンツを変更できるという処理もサポートされています。 このような処理の例を次に示します。
これらの処理はすべて、同じページがわずかに異なる状態で再レンダリングされるという点で似ています。 このような変更は、ユーザーがコンテキストを失って現在の作業から離れてしまうことがないように、シームレスに実装するのが理想的です。
開発者は、このような動作をWebページに追加する場合にしばしば困難な決定に直面します。 これらの処理はすべて、ユーザー操作に応答してページ全体をリフレッシュするという非常に単純なソリューションを使用して実装できます。 簡単ですが、このソリューションが常に望ましいわけではありません。 全ページ・リフレッシュは時間がかかる場合があるため、アプリケーションの応答が遅いという印象をユーザーに与えてしまいます。 別のオプションとして、JavaScript(またはその他のクライアント側スクリプト・テクノロジ)を使用してこのような処理を実装する方法があります。 この場合、応答時間は短縮されますが、複雑性が増し、移植性が低下します。 JavaScriptは、イメージの更新のような単純な処理には適しています。 しかし、表内のデータのスクロールや、カスタムJavaScriptコードの記述といった複雑な処理の場合、非常に困難な作業になる可能性があります。
Oracle ADF UIXでは、全ページ・リフレッシュとカスタムJavaScriptソリューションの短所のいくつかを回避する、部分ページ・レンダリング(PPR)というソリューションが用意されています。 UIXの部分ページ・レンダリング機能では、ページの一部分のみを再レンダリングできます。 PPRでは、全ページ・レンダリング・ソリューションと同様に、中間層のアプリケーションにリクエストを送り返して新しいコンテンツをフェッチします。 ただし、PPRを使用してページが更新される場合は、変更されたコンテンツのみがブラウザに返されます。 UIXでは、新しいコンテンツがWebページに自動的にマージされます。 最終的に、カスタムJavaScriptコードを記述することも、全ページ・リフレッシュでよくあるようにコンテキストを失うこともなくページは更新されます。
部分ページ・レンダリングのプロセスは、部分ページ・イベント、部分ページ・レンダリング渡しおよび部分ページ置換の3つの主要な領域に分けられます。
部分ページ・イベントは、ブラウザが新しいコンテンツを要求するためにアプリケーションに送信するリクエストです。 部分ページ・イベントは、全ページ・イベントとよく似ています。 たとえば、ユーザーがtable
Bean内の新規レコードにナビゲートすると、部分ページ・イベントの場合でも全ページ・イベントの場合でも、value
イベント・パラメータを持つgoto
イベントがアプリケーションに送信されます。 部分ページ・イベントと全ページ・イベントの間には2つの重要な違いがあります。 1つ目は、部分ページ・イベントでは、全ページ・イベントにはない部分ページ・レンダリング固有のイベント・パラメータが指定されることです。 たとえば、部分ページ・イベントには、再レンダリングの必要なノード(部分ターゲットと呼ばれる)のセットを識別するイベント・パラメータが含まれる場合があります。 部分ページ・イベントと全ページ・イベントの2つ目の違いは、イベントが送信される方法です。
全ページ・イベントの場合と異なり、部分ページ・イベントの送信は、ブラウザによって現在のページが強制的に再ロードされないような方法で行う必要があります。 この機能を実装するため、UIXの部分ページ・レンダリングでは、ブラウザと中間層で実行されているWebアプリケーションとの通信チャネルとして非表示インライン・フレーム(iframe)を使用します。 部分ページ・イベントの送信は、非表示iframe内のナビゲーションを強制実行して行われます。これにより、リクエストが中間層のアプリケーションに送信されます。 iframeは非表示なので、部分ページ・イベントを送信してページの一部をレンダリングするプロセスは、現在のページのコンテンツを破棄することなく内部で行われます。
アプリケーションは、部分ページ・イベントを受け取ると、レンダリングする部分ターゲット・セットを判別し、部分ページ・レンダリング渡しを実行します。 部分ページ・レンダリング渡しは、全ページ・レンダリング渡しと似ています。 どちらの場合も、UINodeツリー内の各ノード上でrender()
をコールすることによってUINodeツリーが横断されます。 ただし、部分ページ・レンダリングの場合は、部分ターゲットによって生成されたコンテンツのみが実際にブラウザに送り返されます。 他のコンテンツはすべて破棄されます。 したがって、部分ページ・レンダリング渡しと全ページ・レンダリング渡しのスコープは、レンダリングされるUINodeの数においては似ていますが、部分ページ・レスポンスの場合は変更されたコンテンツのみがブラウザに送り返されるため、一般に全ページの場合よりもはるかに小さくなります。
PPRのプロセスの最後は、部分ページ置換です。 ブラウザが部分ページ・レスポンスを受け取ると、各部分ターゲット・ノードの新規コンテンツが非表示iframeからメイン・ブラウザ・ウィンドウにコピーされて、ターゲット・ノードごとに既存のコンテンツが置換されます。 したがって、たとえば表のナビゲーションでは、ページ全体ではなく表自体のコンテンツのみが置換されます。 ブラウザは変更に応答してリフローを行い、ページ全体を再レンダリングすることなく、ユーザーに新しいコンテンツを表示します。
まとめとして、部分ページ・レンダリングで行われる一連のステップを次に示します。
部分ページ・レンダリング・プロセスではカスタムJavaScriptコードは必要ないので注意してください。
PPRの使用可能な要素は、それぞれpartialRenderMode
およびpartialTargets
という2つの新しい属性をサポートしています。 partialRenderMode
属性は、特定のコンポーネントについて部分ページ・レンダリングを使用可能にするかどうかを制御します。 この属性は、none
、self
、multiple
の3つのうちいずれかの値に設定できます。 デフォルト値はnone
で、部分ページ・レンダリングを使用不可にすることを指定します。 partialRenderMode
属性をself
に設定すると、部分ページ・レンダリングを使用してコンポーネント自体を更新することを指定します。 これが最も一般的な設定です。 multiple
モードはpartialTargets
属性とともに使用され、各部分ページ・イベントに応答して複数の部分ターゲットを再レンダリングすることを指定します。
したがって、たとえば部分ページ・レンダリングを使用して表自体をリフレッシュするように指定するには、次のようにpartialRenderMode
を設定します。
<table id="table-id" partialRenderMode="self">
表が更新されるたびに複数の依存フィールドを更新するように指定するには、partialTargets
属性とともにmultiple
モードを使用します。
<table id="table-id"
partialRenderMode="multiple"
partialTargets="dependent-id1 dependent-id2 dependent-id3">
複数の部分ターゲットを指定するとき、部分ページ・イベントを起動するコンポーネントのIDは、部分ターゲットのリストに暗黙的に含まれるので注意してください。 このため、前述の例では、表のID(table-id)は自動的に部分ターゲットとみなされるので、このIDをpartialTargets
値に含めないでください。
table
コンポーネントの場合、partialRenderMode
をself
またはmultiple
に設定すると、次の処理について部分ページ・レンダリングが有効になります。
hideShow
およびhideShowHeader
コンポーネントの場合、部分ページ・レンダリングを使用して非表示処理と表示処理の両方が最適化されます。 subTabLayout
コンポーネントでは、タブの切替え時に、部分ページ・レンダリングを使用してそのコンテンツを更新します。 hGrid
コンポーネントでは、すべてのイベントで部分ページ・レンダリングを使用します。
partialRenderMode
属性の設定の他に、部分ページ・レンダリングを使用可能にするために必要な条件がいくつかあります。 これらの条件については、以降の各セクションで説明します。
部分ページ・レンダリングを使用可能にするためには、UINode
階層内にbody
Beanが存在している必要があります。 部分ページ・レンダリングを利用するUIXページは、次のような構造を持つ必要があります。
<page xmlns="http://xmlns.oracle.com/uix/controller">
<content>
<document xmlns="http://xmlns.oracle.com/uix/ui">
<contents>
<!-- The body bean is required -->
<body>
<contents>
<!-- Components which fire partial page events can go here -->
</contents>
</body>
</contents>
</document>
</content>
</page>
body
が存在しないと、部分ページ・レンダリングは失敗します。 ほとんどのUIX XMLページでは、body
は自動的に追加されます。document
を使用するページのみ、明示的にbody
要素を追加する必要があります。 ただし、JavaおよびUIX JSPの開発者は、BodyBean
と<uix:body>
をそれぞれ明示的に使用する必要があります。
部分ページ・レンダリングを介して再レンダリングする可能性のあるノードには、ID属性の値を指定する必要があります。 たとえば、hideShow
Beanの部分ページ・レンダリングを使用可能にする場合、次のコードでは不十分です。
<hideShow partialRenderMode="self">
次のようにID属性も指定する必要があります。
<hideShow id="some-unique-id" partialRenderMode="self">
このIDは、部分ページ・レンダリング・プロセスの間、いくつかの重要な役割を果たします。 まず、部分ページ・イベントでは、再レンダリングの対象となる部分ターゲットのセットがIDで識別されます。部分ページ・レンダリングの横断中は、各部分ターゲット・ノードのIDを調べることにより、これらのノードがUINodeツリー内に配置されます。 最後に、部分ページ・コンテンツがブラウザに送り返されるとき、IDを使用して、部分ページ置換のためにブラウザのDOMツリー内にターゲット・ノードが配置されます。
部分ページ・レンダリングは、Configuration.DISABLE_PARTIAL_RENDERING
プロパティの設定がBoolean.TRUE
でない場合に使用可能になります。 デフォルトでは、このプロパティは設定されていないため、部分ページ・レンダリングは使用可能です。 部分ページ・レンダリングを無効にするには、このプロパティを明示的に設定する必要があります。
Configuration
APIの取扱いの詳細は、「ADF UIXの構成」のトピックを参照してください。
部分ページ置換の際、新しく生成されたコンテンツは、非表示iframeからiframeの親ウィンドウに表示のためコピーされます。 新しいコンテンツにスクリプトが含まれる場合、それらのスクリプトも同様に親ウィンドウ内で明示的に実行されます。 この処理が必要なのは、スクリプトで定義されている関数または変数を親ウィンドウから利用可能にするためです。 ただし、スクリプトそのものがコンテンツを生成するような場合、親ウィンドウ内でのスクリプトの実行によって問題が発生することがあります。 document.write()
またはdocument.writeln()
をコールすると親ウィンドウのコンテンツが完全に置換されるため、これらをコールするスクリプトを親ウィンドウ内で実行しないでください。
UIXでは、ある特定のスクリプトがコンテンツを生成する(つまり、document.write()
またはdocument.writeln()
をコールする)かどうかを自動的に判別できないため、クライアントがこのようなスクリプトを明示的に指定する必要があります。 これを指定するには、script
BeanのgeneratesContent
ブール属性を使用できます。 generatesContent
属性は、デフォルトで、スクリプトがコンテンツを生成しないことを示すfalseに設定されます。 部分ページ・レンダリングを使用するクライアントは、document.write()
またはdocument.writeln()
をコールするスクリプトがあれば、例として次のように属性をtrueに設定してください。
<!-- Explicitly specify generatesContent="true", since
this script calls document.write() -->
<script generatesContent="true">
document.write("Hello, World!");
</script>
コンテンツを生成するスクリプトをこの方法で指定しない場合、部分ページ・リクエスト置換により、スクリプトによって生成されたコンテンツのみでページ全体が置換されることがあります。
部分ページ・レンダリングが使用可能になると、コンポーネントは非表示iframeを使用して部分ページ・イベントをアプリケーションに送信します。 UIXサーブレットは、部分ページ・イベントで指定された部分ターゲット・ノードをレンダリングすることにより、これらのイベントを自動的に処理します。 このため、UIXサーブレットのクライアントは、部分ページ・イベントを取り扱う際に何も変更する必要はありません。 既存のUIXサーブレット・イベント・ハンドラは、部分ページ・イベントと全ページ・イベントの両方にわたって再利用できます。 ただし、カスタム・コントローラを使用するアプリケーションについては、部分ページ・イベントの検出、レンダリングする部分ターゲットのセットの判別、および要求されたコンテンツのレンダリングを行うようにその機能を拡張する必要があります。
部分ページ・レンダリングを利用するアプリケーションは、部分ページ・イベントと全ページ・イベントを区別できる必要があります。 その区別は、アプリケーションのコントローラが行います。 コントローラは、リクエストのたびに(HttpServletRequest
オブジェクトまたはoracle.cabo.share.data.ServletRequestParameters
オブジェクトを指定して)UIX PartialPageEventUtils.createPartialPageContext()
メソッドをコールすることによって、部分ページ・イベントと全ページ・イベントを区別します。 このメソッドは、到着したリクエストを調べて、そのリクエストが部分ページ・イベントかどうかを判別します。 リクエストが部分ページ・イベントであれば、PartialPageContext
オブジェクトが作成され、返されます。 PartialPageContext
オブジェクトは、部分ページ・レンダリングに関連する状態をカプセル化します。 たとえば、PartialPageContext
は、レンダリングする部分ターゲットのセットを定義します。
全ページ・イベントの場合、createPartialPageContext()
はNULLを返します。 このように、コントローラは、このメソッドにより返された値をチェックするだけで、全ページ・イベントと部分ページ・イベントを区別できます。 全ページ・イベントの場合、コントローラは通常の処理を続行できます。 部分ページ・イベントの場合、コントローラは、必要なターゲット部分のみがレンダリングされるように追加の処理を実行する必要があります。
それぞれの部分ページ・イベントで、再レンダリングする必要のある部分ターゲットを1つ以上指定できます。createPartialPageContext()
は、要求されたターゲットのセットを使用してPartialPageContext
を自動的に初期化します。 ただし、特定のイベントを処理する場合に、レンダリングする部分ターゲットのセットの変更が必要なアプリケーションもあります。 たとえば、表とグラフのイメージの両方が含まれるページで、表が更新されるたびに表とグラフの両方を再レンダリングする必要がある場合などです。 この場合、部分ページ・イベントで表の再レンダリングしか指定されていなくても、アプリケーションが介入して、グラフも同様にレンダリングされるように部分ターゲットのセットを明示的に変更することができます。
PartialPageContext
には、部分ターゲットの追加と削除を行うためのaddPartialTarget()
およびremovePartialTarget()
というメソッドがあります。 これらのメソッドをレンダリングの前にコールして、レンダリングする部分ターゲットのセットを変更できます。 UIXサーブレット・クライアントの場合、これらのメソッドをコールする場所として最もわかりやすいのは、UIXサーブレット・イベント・ハンドラです。 クライアントは、PartialPageEventUtils.getPartialPageContext()
メソッドをコールすることにより、UIXイベント・ハンドラからPartialPageContext
を取得できます。
部分ターゲットのセットが判別され、アプリケーション・ロジックが実行されたら、必要なコンテンツをレンダリングして部分ページ・イベントに応答します。 部分ページ・レンダリングの実行は、全ページ・レンダリングの場合と非常に似ています。 唯一の違いは、レンダリングに先立ってRenderingContext
にPartialPageContext
を設定する必要があることです。 これは、PartialPageUtils.setPartialPageContext()
メソッドを使用して設定できます。 UIXサーブレットは部分ページ・イベントを処理するときにこのメソッドを自動的にコールするため、UIXサーブレット・クライアントが特別な操作を行う必要はありません。
また、カスタム・コントローラを使用するアプリケーションの場合は、RenderingContext
にPartialPageContext
を設定し、なおかつレンダリングを実行するPartialPageUtils.renderPartialPage()
という便利なメソッドをコールすることもできます。
つまり次のようになります。
node.render(renderingContext);
このメソッドではなく、アプリケーションは次のメソッドをコールします。
PartialPageUtils.renderPartialPage(renderingContext,
node,
partialPageContext);
部分ページの場合も全ページの場合も、UINodeツリーの同じルート・ノードをレンダリングする必要があるので注意してください。 つまり、部分ページ・レンダリング渡しで部分ターゲット・ノードのセットのコンテンツしか生成されない場合でも、UINodeツリー全体を横断することが必要になります。 また、NULLのPartialPageContext
を使用してrenderPartialPage()
をコールする方法も便利です。この場合、通常の全ページ・レンダリングが実行されます。
部分ページ・イベントの処理でエラーが発生した場合、要求された部分ターゲット・ノードをレンダリングするだけでは不十分である可能性があります。 アプリケーションではエラーに関する追加情報をエンド・ユーザーに提供する必要があります。 アプリケーションは、新しいエラー・ページを表示したり、部分ページ・イベントで明示的に要求されていないノードを部分ターゲットのセットに追加して、追加情報を提供できます。
部分ページ・イベントに応答してエラー・ページをレンダリングするには、エラー・ページのUINodeツリー上のUINode.render()
をコールするだけでは不十分です。 部分ページ・イベントは非表示インライン・フレームを介して送信されることに注意してください。 ブラウザに送り返されたコンテンツは、まずインライン・フレーム内に表示されます。エンド・ユーザー向けに表示するには、親ドキュメント・ウィンドウにコンテンツを明示的にコピーする必要があります。 このため、新しいUINodeツリー上のUINode.render()
をコールした場合、必要なエラー・ページ・コンテンツは生成されても表示されません。 アプリケーションは、PartialPageUtils.renderFullPage()
メソッドをコールして新しい全ページのコンテンツをレンダリングする必要があります。 renderFullPage()
メソッドを使用すると、確実に、UINodeツリーの全コンテンツがブラウザに送り返され、表示のために非表示iframeから親ウィンドウ内にコピーされます。
UIXサーブレットをベースにしたアプリケーションでは、部分ページ・イベントを取り扱うEventHandler
から別のPage
を返すだけで、これと同じ結果を達成できます。 この場合、UIXサーブレットがアプリケーションにかわってrenderFullPage()
を自動的に呼び出します。
部分ページ・イベントに応答してエラー・ページをレンダリングするもう1つの方法は、PartialPageUtils.forceRedirectURL()
をコールし、アプリケーションで指定するURLへクライアントを強制的にリダイレクトしてエラーを表示することです。 部分ページ・レスポンスをレンダリングするかわりに、または部分ページ・レンダリング渡し中にエラー(または例外)が発生した場合に、このメソッドをコールできます。 UIXサーブレットを使用しており、EventHandlerでエラーが発生した場合は、RedirectUtils.getRedirectPage()
をコールして、ブラウザを別のURLへリダイレクトするページ・オブジェクトを返すことができます。 これは、全ページ・イベントおよび部分ページ・イベントのどちらでも機能します。
部分ページ・レンダリング渡しの間にエラーが検出された場合は、新しい部分ターゲットを追加することによって、部分ページ・レスポンスにエラー情報を組み込むことができます。 たとえば、部分ターゲットを移入するための問合せ中にエラーが発生した場合、要求された部分ターゲットのセットにMessageBox
BeanのIDが明示的に含まれていなかったとしても、アプリケーションはMessageBox
Bean内にエラー・メッセージを表示します。 PartialPageContext.addPartialTarget()
メソッドをコールして、ID属性値で指定された新しいUINodeを、部分ページ・レンダリング渡しでレンダリングされるノードのセットに追加することを指定できます。
新しく追加された部分ターゲットを適切にレンダリングして表示するには、必要な条件がいくつかあります。 最もわかりやすい条件は、部分ターゲットの候補であるUINode上にID属性が指定されていることです。 また、新しい部分ターゲットのレンダリングはaddPartialTarget()
のコール後に行われる必要があります。 これは、一般的に、エラー情報の表示に使用されるUINodeを、そのUINodeツリー内の対象となる可能性のある部分ターゲットより下に配置するということを意味しています。 最後の条件は、新しい部分ターゲットが、現在のページの以前の全ページ・レンダリングによってなんらかの形態でレンダリングされていることです。 少なくとも、クライアント側のDOMツリーに、エラー・ノードのIDを持つノードが存在している必要があります。このノードでコンテンツが表示されない場合でも同じです。 必要なIDを持つノードがクライアント側のDOMツリー内に見つからない場合、エラー・メッセージの内容はドキュメントにコピーされません。
多くの場合、リンクやボタンのクリック、選択コントロールからの選択などのユーザー・アクションに応答して、イベントが起動されます。 しかし、応答する必要があるすべてのユーザー・アクションが、中間層またはサーバー側ロジックで対応可能なイベントを生成させるわけではありません。 これは、ClientAction APIを導入することによって解決します。 ClientAction APIを使用すると、サポートされたコンポーネントから、任意のイベントおよびパラメータを送信できます。 イベントは、部分ページ・イベントまたは全ページ・イベントのどちらでもかまいません。 また、ClientAction APIでは、この機能を使用するためにカスタムJavaScriptを記述する必要がありません。
基本的なクライアント・アクションは、fireAction
およびfirePartialAction
の2つです。 これらのアクションを使用すると、要素に対するユーザー・イベントに応答して、パラメータの任意のリストを使用した任意のイベントを起動できます。 すべてのクライアント・アクションはprimaryClientAction
要素にラップされるため、primaryClientAction
は、使用可能な任意の要素の有効な子となります。 クライアント・アクションを使用可能な初期要素は、button
、checkBox
、choice
、link
、radioGroup
、radioSet
、singleSelection
およびtextInput
です。
fireAction
は、event
、source
、formSubmitted
およびvalidated
の4つの属性をサポートしています。 アクションがアクティブになると、event
属性およびsource
属性に設定された値はそのまま送信されます。formSubmitted
属性およびvalidated
属性は、イベントの送信にフォーム送信を使用するかどうか、およびフォーム送信を使用する場合は送信前にクライアント側のValidatorを起動するかどうかを制御します。ユーザーが親要素を更新すると(textInput
フィールドのテキストの変更、ラジオボタンの選択、チェック・ボックスのクリックなどを実行した場合)、fireAction
によって指定されたイベントが起動されます。 イベントは、URLの更新またはフォーム送信を使用して配信できます。 次に例を示します。
<link text="fire link event">
<primaryClientAction>
<fireAction event="linkAction"
formSubmitted="false"/>
</primaryClientAction>
</link>
この例の場合、リンクがクリックされると、linkActionイベントがサーバーに配信されます。 送信では、フォーム送信は使用されず、現在のURLに「event=linkEvent」を追加してURLが置き換えられます。 デフォルトではフォーム送信が使用されます。formSubmitted
属性を省略するか、この属性をtrueに設定すると、リンクがクリックされた場合に最初の囲んでいるフォームが送信されます。
クライアント・アクションfirePartialAction
は、fireAction
と同じように動作しますが、イベントを部分ページ・イベントとして配信する点が異なります。 クライアント・アクションを使用可能なすべてのコンポーネントでは、firePartialAction
を使用できるため、PPRも使用可能になります。 ターゲット・ブラウザで部分ページ・レンダリングがサポートされていない場合は、適切なトリガーがレンダリングされます(たとえば、選択リストの横のボタンをクリックすると、イベントが配信されます)。 また、2つの追加属性がサポートされています。targets
は部分ターゲットのリストを受け取り、triggerText
は(必要に応じて)トリガー・ボタンでレンダリングするテキストを受け取ります。
通常、複雑なイベントを処理するには、イベント名とソース以外の情報も必要になります。 そのため、クライアント・アクションformSubmittedは任意のパラメータをサポートしています。 次のように構成すると、dogEventという名前の部分ページ・イベントと2つの追加パラメータが送信されます。
<link text="update dog names">
<primaryClientAction>
<firePartialAction event="dogEvent"
formSubmitted="true"
source="dogNames"
targets="someTargetID">
<parameters>
<parameter key="alphaDog" value="Oneone"/>
<parameter key="betaDog" value="Kwakasi"/>
</parameters>
</firePartialAction>
</primaryClientAction>
</link>
部分ページ・レンダリングの実装には、ブラウザのDOM APIを介して任意のコンテンツを変更できることが必要です。 現在、部分ページ・レンダリングがサポートされているのは次のブラウザのみです。
その他のプラットフォームの場合、UIXでは自動的に全ページ・レンダリングが実行されます。 将来的に、PPRは広範囲のブラウザでサポートされる予定です。 ただし、Netscape 4.xではDOMサポートに制限があるため、部分ページ・レンダリングがNetscape 4.xでサポートされる予定はありません。
また、PPRで使用されるクライアント側DOM変更によって、スクリーン・リーダーは、部分アクションを起動したコンポーネント以降のページを読み上げます。 部分リクエストの場合、スクリーン・リーダーは全ページの再読上げを行いません。 これによって、スクリーン・リーダーのユーザーはページ・コンテキストを維持できます。 部分ターゲットは部分リクエストを起動するコンポーネントの後に配置する必要があります。そうしないと、スクリーン・リーダーは更新された部分ターゲットを読み上げません。
PPRを使用可能なコンポーネント、または部分ページ・レンダリングがコンポーネントの機能の一部またはすべてにおいて重要なコンポーネントは、定期的に追加されています。 現在、PPRを使用可能なコンポーネントは、table
、hGrid
、hideShow
、hideShowHeader
、subTabLayout
、lovInput
およびprocessing
です。 これまでに、table
、hGrid
、hideShow
、hideShowHeader
およびsubTabLayout
でPPRを使用する方法について説明しました。 processing
要素は、PPRモードの場合、索引付けされた子とともに定期的に自動リフレッシュされます。 lovInput
要素は、PPRを使用し、事前定義済の有効な値のリスト(「ADF UIXでのLOVの作成」のトピックを参照)に基づいて、フィールドの実行時の検証および更新を実装します。
ClientAction APIを使用すると、サポートされたコンポーネントから、任意のイベントおよびパラメータを送信できます。 イベントは、部分ページ・イベントおよび全ページ・イベントのどちらでもかまいません。 クライアント・アクションを使用可能な初期要素は、button
、checkBox
、choice
、link
、radioGroup
、radioSet
、singleSelection
およびtextInput
です。
PPRを使用可能なコンポーネントおよびクライアント・アクションを使用可能なコンポーネントのリストを次に示します。
部分ページ・レンダリングおよびクライアント・アクションは、多様なコンポーネントで使用できるようになりました。 将来的には、使用可能なコンポーネントの追加、更新の頻度の調整、および様々な一般的タスクをサポートするクライアント・アクションの追加によって、これらの機能をより広範囲に利用できるようになる予定です。 当面、UIXクライアントで、現在使用可能なコンポーネントの部分ページ・レンダリングおよびクライアント・アクションを利用することをお薦めします。 また、現在の実装や将来的な方向性に関するご意見やご感想がありましたらお知らせください。
Copyright © 2001, 2004, Oracle Corporation.
All rights reserved.