UIX開発者ガイド | ![]() 目次 |
![]() 前へ |
![]() 次へ |
このトピックでは、UIXアプリケーションのすべての部分の構成情報を管理するために使用する、Configuration APIについて説明します。ここでは、次の項目について説明します。
Configuration APIは、グローバル構成情報をUIXフレームワークのすべての部分に渡すためのUIXのメカニズムです。構成情報は、URL、ファイル・システム・パスおよびその他多数のプロパティという3つのタイプの情報から構成されます。URLとパスはどちらも、イメージやスタイルシートなどのUIXフレームワークで使用されるUIXリソースの場所を示すために使用されます。すべての構成情報は、不変のベース・クラスであるConfiguration
クラスのインスタンスを介してアクセスされます。Configuration APIには、アプリケーションでデフォルトの構成値をオーバーライドする際に使用する、関連する不定のサブクラスConfigurationImpl
も用意されています。
Configuration
オブジェクトはJavaから作成できますが、構成を作成するための単純なXML書式を提供する、WEB-INF
ディレクトリにあるuix-config.xml
ファイルを使用した方がはるかに簡単です。
Configuration
オブジェクトは、ControllerのBajaContext
、ComponentsのRenderingContext
、ImagesのImageContext
など、様々なプロジェクト固有のコンテキストを介して、UIXフレームワーク全体に渡されます。1つのHTTPリクエストに対するサービスのために作成され、レスポンスの完了時に解放されるその他のコンテキスト・オブジェクトとは異なり、Configuration
オブジェクトはアプリケーションの存続期間を通じて存在します。このため、アプリケーションでは構成の初期化を一度実行した後、単一のConfiguration
オブジェクト(または少数のConfiguration
オブジェクト)を再利用し、すべてのリクエストにサービスを提供できます。
UIXフレームワークではイメージおよびスタイルシートなどの様々なリソース・ファイルを使用するため、UIXで生成されたWebページで使用するためには、これらのファイルをWebサーバーにインストールする必要があります。多くの場合、Webアプリケーションでは、アプリケーション固有のリソースを特定の標準ディレクトリにインストールします。たとえば、あるアプリケーションで、イメージを/imagesディレクトリにインストールする場合があります。この方法の問題点は、異なるアプリケーション間でリソース・ファイル名が競合する可能性がある点です。2つの異なるアプリケーションが/images/logo.gifまたはstyles.cssを参照すると仮定します。この2つのアプリケーションは、1つのWebサーバー上では共存できません。UIXフレームワークでは、このようなリソース・ファイル名の競合を、次の2つの方法で回避します。第1に、UIXフレームワークでは、自分のリソースを/caboの下のデフォルト・リソース・ディレクトリに配置することでパーティション化します。第2に、UIXフレームワークでは、Configuration APIを介してリソースのデフォルトの場所をオーバーライドできます。
次の表に、各UIXリソース・ディレクトリの名前、デフォルトの場所および内容を示します。名前は、Configuration
クラスで定義されたディレクトリ定数を使用して指定されています。デフォルトの場所は、相対URLで指定されています。
Java名 | XML要素 | デフォルトの場所 | 内容 |
---|---|---|---|
BASE_DIRECTORY | <base-directory> | /cabo/ | その他のUIXリソース・ディレクトリすべてを含む。 |
IMAGES_DIRECTORY | <images-directory> | /cabo/images/ | UIX Componentsで使用される静的イメージを含む。 |
STYLES_DIRECTORY | <styles-directory> | /cabo/styles/ | UIXで使用されるXML Style Sheet文書を含む。 |
JSLIBS_DIRECTORY | <jslibs-directory> | /cabo/jsLibs/ | UIXで内部的に使用されるJavaScriptライブラリ・ファイルを含む。 |
JSPS_DIRECTORY | <jsps-directory> | /cabo/jsps/ | UIXで内部的に使用されるJSPファイルを含む。 |
IMAGES_CACHE_DIRECTORY | <images-cache-directory> | /cabo/images/cache/ | UIXで動的に生成されるアプリケーション固有のイメージを含む。 |
STYLES_CACHE_DIRECTORY | <styles-cache-directory> | /cabo/styles/cache/ | UIXで動的に生成されるCascading Style Sheetファイルを含む。 |
UIXリソース・ディレクトリの構造は、階層構造です。親ディレクトリの場所を変更すると、子ディレクトリの場所も移動します。たとえば、IMAGES_DIRECTORYを変更するとIMAGES_CACHE_DIRECTORYも暗黙的に変更され、BASE_DIRECTORYを変更するとその他すべてのディレクトリも暗黙的に変更されます。
ここに定義したデフォルトの場所はすべて、アプリケーション固有の値で構成されているConfigurationImpl
インスタンスを使用して、またはWEB-INF/uix-config.xml
に要素を追加して変更できます。
uix-config.xml
の編集UIXでは、1つのXMLファイルで簡単に構成オブジェクトを設定できます。このファイルは、WEB-INF
ディレクトリのuix-config.xml
内に格納されています。これは、web.xml
がサーブレットやファイル・マッピングを列記する同じWEB-INF
ディレクトリです。(このディレクトリはJava Servlet 2.1以上でのみ存在します。)
WEB-INF/uix-config.xml
ファイルはいつも同じ要素、<configurations>
で始まり(終わり)ます。その要素内に、UIXを構成する一連の要素が含まれています。
<?xml version="1.0" encoding="ISO-8859-1"?>
<configurations xmlns="http://xmlns.oracle.com/uix/config">
<!-- A series of properties global to your application -->
<application-configuration>
<uix-path>c:\yourDirectory\uixFiles\</uix-path>
<check-modified>true</check-modified>
<ui-extensions>
<template-library>templates/library.uit</template-library>
</ui-extensions>
</application-configuration>
<!-- A set of default properties -->
<default-configuration>
<base-path>
<context-uri>uixInst</context-uri>
</base-path>
<help-provider>
<ohw-servlet-url>http://yourserver.com/ohw</ohw-servlet-url>
</help-provider>
</default-configuration>
<!-- An alternate configuration that disables accessibility features -->
<configuration name="noADA">
<accessibility-mode>inaccessible</accessibility-mode>
</configuration>
<!-- And another configuration that maxes out accessibility features -->
<configuration name="maxADA">
<accessibility-mode>screenReader</accessibility-mode>
<style-sheet-name>myBigStyleSheet.xss</style-sheet-name>
</configuration>
</configurations>
構成ファイルで使用できるすべての要素についてはすぐ後述しますが、この例を一覧することによって概略がつかめるはずです。
各uix-config.xml
ファイルには次の3つのセクションがあり、各セクションはオプションです。
<application-configuration>
セクションが、Webアプリケーション全体に対してグローバルなプロパティを定義します。
<default-configuration>
セクションが、デフォルトとして使用される(ただしオーバーライドは可能な)プロパティを定義します。
<configuration>
要素で、<default-configuration>
の名前付きオーバーライドを定義します。
この例では、<application-configuration>
がUIXに、c:\yourDirectory\uixFiles\ディレクトリで .uixファイルを検索するように指示しています。(これによってUIXがイメージ、JavaScriptライブラリなどを検索する場所に影響はありません。UIXファイルのみです。)キャッシュされたバージョンを削除してファイルを再ロードできるように、UIXがファイルの変更時に注意を払うことも指示しています。これによってデバッグがはるかに容易になりますが、パフォーマンスへの影響はわずかです。最後に、1つのテンプレート・ライブラリを登録しました。これによってUIXユーザーは各ページでライブラリを手動でインポートする必要がなくなります。
次に、<default-configuration>
は2つのプロパティを設定します。最初に、UIXのインストール可能ファイルがあるルート・ディレクトリの<base-path>
を変更します。次に、Oracle Help for the Web(OHW)サーブレットの示唆によりUIXを指し示します。これらの数行のみで、すべてのUIXページが状況依存ヘルプをサポートするようになります。(Oracle Help for the Webは、オラクル社が無償で提供している強力なWebベースのヘルプです。詳細は、Oracle Technology Networkを参照してください。)
最後に、アクセシビリティ・サポートのレベルを調整するため、2つの名前付き<configuration>
オプションを追加します。1つのオプションはアクセシビリティ機能を使用不可にし、もう1つのオプションはアクセシビリティをデフォルトよりも拡張します。これらの構成によって特定のユーザー向けに出力を調整できますが、ユーザーが(設定ページなどで)取得する環境は依然としてアプリケーションに依存します。また、これらの<configuration>
の選択肢は両方とも<default-configuration>
で設定された値をそれぞれ継承するため、OHWサーバーまたはベース・パスを再指定する必要はありません。
<application-configuration>
要素はいくつかの子をサポートします。これらの子の順序は意味を持っています。これらは、ここで記述されるとおりに組み込まれる必要があります。
UIXが .uixおよび .uitファイルを検索する場所を再定義します。(これによってUIXがイメージ、JavaScriptライブラリなどを検索する場所に影響はありません。UIXページおよびテンプレートのみです。)デフォルトでは、UIXは、Webアプリケーションのルートでこれらのファイルを検索します。絶対パスまたはWebアプリケーションへの相対パスを使用できます。
例:
<uix-path>c:\somePath\file.uix</uix-path>
動的に生成されたイメージについて、ファイル変更日付がチェックされるか無視されるかを決定します。イメージ・キャッシュ内のファイルがまだ存在することを確認するかどうか、判断する場合にも使用されます。デフォルトはtrueですが、パフォーマンスをわずかでも向上させるためfalseに設定することもできます。
例:
<check-images-modified>false</check-images-modified>
動的に生成されたスタイルシート・ファイルについて、ファイル変更日付がチェックされるか無視されるかを決定します。スタイルシート・キャッシュ内のファイルがまだ存在することを確認するかどうか、判断する場合にも使用されます。デフォルトはtrueですが、パフォーマンスをわずかでも向上させるためfalseに設定することもできます。
例:
<check-styles-modified>falselt;/check-styles-modified>
uiXMLファイル変更日付がチェックされるか無視されるかを決定します。有効な値はtrueおよびfalseのみです。これをtrueに設定して開発した方が簡単ですが、デプロイされたアプリケーションでは少し効率が下がります。
例:
<check-modified>true</check-modified>
<display-parse-errors>要素は、UIXファイルの解析時の問題にUIXがどのように対応するかを決定します。trueに設定されると、UIXは完全に書式設定されたエラー・ページを表示します。falseに設定されると、検出されたエラーは記録しますが、正常に解析されたページ部分はすべて表示します。
例:
<display-parse-errors>false</display-parse-errors>
<lenient-date-formats>要素は、日付書式設定を柔軟にするかどうかを決定します。これはoracle.cabo.share.nls.MutableDateFormatContext@setLenientを使用してJavaコードから設定することもできます。柔軟性がアクティブになっているとき、日付フィールドは、要求されたサーバー側書式に正確には一致していない(ただし明瞭な解釈はある)書式を許容します。クライアント側コードがフィールドの修正を試行する一方、サーバー側コードはこれに依存せず、同じ書式セットを受け入れる必要があります。結果的に、この機能は今回デフォルトでオフになっています。(この柔軟性の定義は、月の範囲外の日付を許容するjava.text.DateFormat定義には一致しないので注意してください。)
例:
<lenient-date-formats>false</lenient-date-formats>
<debug-indent-output>要素は、UIXがどのように出力を表示するかを決定します。trueに設定されると、HTMLソースは自動的に適切に出力されます。この値は、UIXがデバッグ・モードの場合のみ参照されます。
例:
<debug-indent-output>false</debug-indent-output>
<debug-flush-on-end-element>要素は、要素が終了するたびに出力を自動的にフラッシュするかどうかを決定します。例外が問題箇所とより明瞭に関連付けられるため、デバッグがより容易になります。ただし出力が適切に印刷される場合のパフォーマンスは遅くなります。これは、デフォルトはfalseに設定されており、デバッグ・モードでのみ使用されます。
例:
<debug-flush-on-end-element>true</debug-flush-on-end-element>
<debug-log-to-console>要素は、標準サーブレット・ログと同様に、記録された情報をコンソールに送信するかどうかを決定します。これは、デフォルトはtrueに設定されており、デバッグ・モードでのみ使用されます。
例:
<debug-log-to-console>true</debug-log-to-console>
<debug-log-request-parameters>要素は、各リクエストのパラメータを記録するかどうかを決定します。これは、デフォルトはtrueに設定されており、デバッグ・モードでのみ使用されます。
例:
<debug-log-request-parameters>true</debug-log-request-parameters>
<debug-log-request-timing>要素は、各リクエストのタイミング情報を記録するかどうかを決定します。これは、デフォルトはfalseに設定されており、デバッグ・モードでのみ使用されます。
例:
<debug-log-request-timing>true</debug-log-request-parameters>
<debug-partial-responses>要素は、部分ページ・レンダリングのデバッグを有効にするために使用されます。部分ページ・イベントは、部分ページ・レスポンスの内容表示が難しい非表示iframeで送信されるため、デバッグを行うのが困難です。<debug-partial-responses>をtrueに設定すると、iframeはページ最上部に表示されます。これによって、特定の部分ページ・イベントについて返された内容を参照することが可能になります。この値は、UIXがデバッグ・モードの場合のみ参照されます。
例:
<debug-partial-responses>true</debug-partial-responses>
<ui-extensions>要素は、UIExtension実装およびテンプレート・ライブラリの両方の自動登録を許容します。これには一連の<extension-class>要素、それに続く一連の<template-library>要素が含まれています。これらは、クライアントが明示的にライブラリを登録しなくても利用できる、UIExtension
実装および .uitテンプレート・ライブラリを順々に定義します。ここでロードされたテンプレート・ライブラリは1回ロードされるだけなので注意してください。これらのライブラリの変更が必要な場合、変更を適用する前にUIXアプリケーションを再起動する必要があります。このため、テンプレートが主要時間帯について十分に準備ができている場合のみ、この機能を使用します。拡張機能の詳細は「UIXの拡張」を、テンプレートの詳細は「uiXMLでのインクルードおよびテンプレート定義」を参照してください。
例:
<ui-extensions> <extension-class>oracle.cabo.data.jbo.ui.JboUIExtension</extension-class> <template-library>templates/firstLibrary.uit</template-library> <template-library>templates/secondLibrary.uit</template-library> </ui-extensions>
UIXでは、デバッグ時に有効にできるいくつかの機能が提供されていますが、これはアプリケーションのデプロイ時には使用しないでください(デプロイされたアプリケーションで問題をデバッグすることが必要な場合以外)。UIXでデバッグ・モードを有効にするには、<application-configuration>のdebug属性をtrueに設定します。
例:
<application-configuration debug="true"> <debug-indent-output>true</debug-indent-output> </application-configuration>
debug-で始まる名前の要素はすべてデバッグ・モードのみの設定とみなされ、デバッグが明示的に有効にされていないかぎり、無視されます。これによって開発者は一連のデバッグ機能を選択でき、それを迅速に有効または無効にできます。
個別に有効または無効にできる機能のほかに、UIXはデバッグ・モードになると自動的にある機能を使用可能にします。
<default-configuration>
要素および<configuration>要素はいくつかの子をサポートします。これらの子の順序に意味はありませんが、<default-configuration>
を組み込む場合は、すべての<configuration>
要素の前に配置します。
構成ファイルは7つのUIXリソース・ディレクトリのいずれにも設定できます。これらのディレクトリは「UIXリソース・ファイル」で列記および説明しました。これらの要素の使用については「UIXリソースの場所の変更」で後述します。
look-and-feel要素は優先されるルック&フィールの名前を定義します。
例:
<look-and-feel>blaf</look-and-feel>
style-sheet-name要素は、使用されるXSSスタイルシートの名前を定義します。このスタイルシートはSTYLES_DIRECTORYで検索されます。XSSの詳細は、「カスタマイズ」のトピックを参照してください。
例:
<style-sheet-name>blaf.xss</style-sheet-name>
accessibility-mode要素は、生成されるアクセシビリティ・サポートのレベルを定義します。有効な値はdefault(デフォルト)、アクセシビリティ機能をオフにするがページ・サイズは改善されるinaccessibleと、スクリーン・リーダーによる操作性向上のためにアクセシビリティを強化する(ただし標準的なブラウザの外観は低下する)screenReaderの3つです。UIXアクセシビリティの詳細は、「アクセシビリティ」のトピックを参照してください。
例:
<accessibility-mode>inaccessible</accessibility-mode>
image-servlet-url要素はUIXのImageServletサーバーにURLを組み込みます。(ローカルでイメージの生成を試行するのではなく)このサーバーはイメージのすべての動的な生成に使用されます。ImageServletの詳細は、「イメージ生成のためのXサーバー構成」のトピックを参照してください。
例:
<image-servlet-url>http://www.example.org/uix/ImageServlet<image-servlet-url/>
headless要素は、ヘッドレス・レンダリングを使用するかどうかを定義します。trueに設定されると、UIXは動的なイメージの生成を試行しません。これは、UNIXプラットフォーム上でイメージを生成するためにXサーバーに接続することをUIXに試行させない場合に使用します。ただしJDK 1.4にアップグレードして問題をすべて回避した方がより賢明であるとも言えます。動的なイメージ生成の詳細は、「イメージの生成」のトピックを参照してください。
例:
<headless>false<headless/>
disable-content-compression要素は、UIXで出力を(たとえば短縮スタイル名で置き換えて)圧縮するかどうかを定義します。(これは出力をZIPファイルなどにするという意味ではありません。)この機能はデフォルトでオンになっていますが、デバッグがより難しくなる可能性があります。
例:
<disable-content-compression>false<disable-content-compression/>
help-provider要素は、ヘルプ・プロバイダの構成を許容します。今回唯一サポートされている構文は、組込み<ohw-servlet-url>要素です。ohw-servlet-urlは、Oracle Help for the Web(OHW)のインストールを示すURLを組み込む必要があります。このプロパティを一度設定すると、すべてのuiXMLおよびUIX Javaページは、状況依存ヘルプの追加をはるかに容易にする2つのデータ・プロバイダ(ui:helpTopicsとui:helpSystem)へのアクセス権を持ちます。
例:
<help-provider> <ohw-servlet-url>http://www.example.org:8888/ohw</ohw-servlet-url> <help-provider/> <!-- Then, in a uiXML page: --> <link text="Show me some help on topic 'Foo'" data:destination="Foo@ui:helpTopics"/>
UIXには、ビルトインの多数の言語に対する翻訳が組み込まれています。ただし、アプリケーションで同じくらい多くの言語がサポートされていない場合、奇妙な結果となる可能性があります。ユーザーは、アプリケーションで提供されたコンテンツをある言語で参照し、UIXで直接提供されたコンテンツを他の言語で参照する場合があります。<supported-locales>要素を使用すると、サポートされるロケールを正確にUIXに通知できます。
<supported-locales>はいつも1つの<default-locale>要素で始まります。<default-locale>要素にはISOロケール定義(en、ja-JPなど)が含まれます。このロケールは、ユーザーが要求したロケールがサポートされているロケールと一致しない場合に使用されます。デフォルトが指定された後、オプションで任意の数の<supported-locale>要素を組み込むことができます。
例:
<supported-locales> <default-locale>en</default-locale> <supported-locale>fr</default-locale> <supported-locale>fr-CA</default-locale> <supported-locale>zh-CN</default-locale> <supported-locale>zh-TW</default-locale> <supported-locales/>
Configuration
の使用方法 レンダリング時にConfiguration
インスタンスを指定しない場合、アプリケーションではデフォルトの構成が使用されます。または、すべてのページのレンダリングにアプリケーション固有の1つのConfiguration
インスタンスが使用されるか、レンダリングごとに少数のインスタンスの中から選択されます。たとえば、ターゲットのコンテンツ・タイプ(HTMLまたはWML)に応じて異なるConfiguration
インスタンスが使用される場合や、ホストされるアプリケーション環境内の異なる顧客にカスタム構成が提供される場合などがあります。
UIX Controllerを使用する場合、UIXPageBroker.getConfigurationName
メソッドをオーバーライドするリクエストごとにConfiguration
を指定できます。
protected String getConfigurationName(
BajaContext context,
Page page)
{
if (_doIWantMyOtherConfig(...))
return "MyOtherConfig";
return "MyConfig";
}
UIX Controllerを使用しない開発者の場合、(uix-config.xml
またはJavaのどちらかで)Configuration
インスタンスが構成され登録されていると、UIX ComponentsのRenderingContext
でsetConfiguration()
をコールすることによってレンダリング時に使用できます。UIX ComponentsのBaseRenderingContext
には、setConfiguration()
のオーバーロードが2つ用意されています。1つはConfiguration
インスタンスを受け取り、もう1つはConfiguration
名を受け取ります。
ConfigurationImpl
インスタンスの作成 アプリケーションでJavaのデフォルトの構成値をオーバーライドする必要がある場合、独自のConfigurationImpl
インスタンスを作成します。構成を作成するには、次の3つの手順に従います。
ConfigurationImpl
インスタンスを作成します。
これらの手順は1回だけ実行されます。次の例は、アプリケーション固有のConfigurationImpl
インスタンスを作成し、登録する方法を示しています。
// Create the ConfigurationImpl instance, specifying a unique name
ConfigurationImpl config = new ConfigurationImpl("iProductConfig");
// Configure the instance with application-specific values
config.putRelativeURI(Configuration.BASE_DIRECTORY, "/iProduct/cabo/");
ServletContext context = _getAServletContext();
// Register the instance
config.register(context);
各ConfigurationImpl
インスタンスに一意の名前を指定し、Configuration.register(ServletContext)
メソッドをコールして登録します。(UIXではregister()
メソッドによるグローバルな構成の登録もサポートされていますが、これはお薦めしません。)これは、UIXのプライベートJSPが使用された場合に、ブラウザとのラウンドトリップによって構成設定が消失することを防ぐために必要です。
UIXリソース・ファイルのデフォルトの場所では、他のアプリケーションのリソース・ファイル名との競合が回避されますが、UIXのリソースをまとめて別の場所に移動することが有効な場合があります。たとえば、複数のUIXアプリケーションがインストールされている環境では、アプリケーションごとにUIXリソースのコピーを保持することが有益です。こうすれば、1つのアプリケーションでUIXの新規バージョンにアップグレードしても、他のアプリケーションで使用されているUIXリソース・ファイルに影響を与えません。(独自のサーブレット・コンテキストにインストールされていないアプリケーションなど、別の方法でパーティション化されていないアプリケーションの場合、これは特に重要です。)
UIXリソース・ディレクトリを変更する最も簡単な方法は、ConfigurationImpl.putRelativeURI()
メソッドまたは<context-uri> XML要素を使用することです。このメソッドでは、移動するディレクトリのキー定数、およびディレクトリの新規の相対URLを受け取ります。次のコードは、1つのリソース・ディレクトリを移動する方法を示しています。
<!-- in XML -->
<jsps-directory>
<context-uri>/iProduct/cabo/jsps/</context-uri>
<jsps-directory>
// In Java:
config.putRelativeURI(Configuration.JSPS_DIRECTORY, "/iProduct/cabo/jsps/");
この変更の結果、UIX Componentsでは、JSPファイルの参照時にURLが<context path>/iProduct/cabo/jsps/という形式で生成されます。アプリケーションでは、UIX ComponentsのJSPが、ファイル・システムの対応するディレクトリにインストールされている必要があります。
UIXリソース・ディレクトリの構造は、階層構造です。親ディレクトリの場所を変更すると、子ディレクトリの場所も移動します。たとえば、次のコードでは、IMAGES_DIRECTORY
と、子のIMAGES_CACHE_DIRECTORY
の両方が変更されます。
<!-- in XML: -->
<images-directory>
<context-uri>/iProduct/images/</context-uri>
</images-directory>
// In Java:
config.putRelativeURI(Configuration.IMAGES_DIRECTORY, "/iProduct/images/");
その結果、UIX Componentsのイメージは、/iProduct/images/の対応するディレクトリにインストールされます。IMAGES_CACHE_DIRECTORY
が明示的に指定されていない場合、UIX Dynamic Imagesで生成されるイメージは、/iProduct/images/cacheの対応するサブディレクトリに作成されます。
同様に、すべてのUIXリソース・ディレクトリは、putRelativeURI()
を1回コールして、BASE_DIRECTORY
の値を変更すること(または<base-directory>要素を使用すること)で移動できます。
これまでに示した例ではすべて、サーブレットのコンテキスト・パスと相対的に解決される相対URLを使用しました。この他に、ConfigurationImpl.putFullURIAndPath()
か、<full-uri>および<full-path>要素の両方を使用して、絶対位置を指定する方法があります。絶対位置は、マシン間でUIXリソースを共有する場合、または他のWebサーバーに処理をオフロードする場合に便利です。たとえば、次の例は、イメージがセカンダリWebサーバーで処理されるようUIXを構成する方法を示しています。
<!-- in XML -->
<images-directory>
<full-path>/net/images/private/httpd/htdocs/cabo/images/</full-path>
<full-uri>http://images.example.com/cabo/images/</full-uri>
</images-directory>
// In Java:
// The full URI to the images directory on the image server
String fullURI = "http://images.example.com/cabo/images/";
// The full file system path to the auto-mounted images directory
String fullPath = "/net/images/private/httpd/htdocs/cabo/images/";
config.putFullURIAndPath(config.IMAGES_DIRECTORY, fullURI, fullPath);
この構成を使用することにより、UIX Componentsのイメージを参照するすべてのURLはhttp://images.example.com/cabo/images/で始まり、images.example.comのWebサーバーで処理されます。イメージ・ファイルの処理をセカンダリWebサーバーにオフロードすると、プライマリ・サーバーで必要な処理量が軽減されるため、応答時間を改善できます。ただし、URLを長くすると、UIX Componentsで参照されるイメージごとに完全なURLが生成されるため、ページ・サイズが大きくなるので注意してください。
実際のパスはマシンによって異なるため、ハードコードされた絶対ファイル・システム・パスをアプリケーションで使用しないでください。ファイル・システム・パスは、デプロイメント時に構成可能である必要があります。これは、パスをインストール・プロセスの中で指定できるようにすることで、可能になります。もしくはフルパスを、(uix-config.xmlなどの)構成ファイルから、またはサーブレットの初期化パラメータを介して取得します。
完全なURLまたはフルパスを使用したカスタム構成が必要なもう1つのケースは、アプリケーションのJSPファイルおよびUIXリソースが、Apache Webサーバー上の別名が付けられたディレクトリにある場合です。Apacheでは、Webサーバーのドキュメント・ルート外にあるディレクトリに、URLの別名を付けることができます。たとえば、Apacheのhttpd.conf構成ファイルの次のエントリにより、/HTML/というURLの別名が作成されます。
Alias /HTML/ "/private/html/"
この別名によって、/HTML/で始まるすべてのURLは、/private/html/ディレクトリ下のパスに変換されます。/private/html/cabo下の別名が付けられたディレクトリにUIXリソースを移動するには、次の構成で十分機能するはずです。
<!-- In XML: -->
<base-directory>
<context-uri>/HTML/cabo/</context-uri>
</base-directory>
// In Java:
config.putRelativeURI(Configuration.BASE_DIRECTORY, "/HTML/cabo/");
/HTML/に別名が付けられていない場合、この構成は正常に機能します。ただし、/HTML/に前述のような別名が付けられている場合、この構成では目的とする結果は得られません。Apacheの別名指定メカニズムは、サーブレット・エンジンによるファイル・システム・パスのレポートに影響します。そのため、UIX Componentsにより生成されるすべてのHTMLに/HTML/cabo/で始まる正しいURLが含まれていても、UIXにより動的に生成されるイメージおよびスタイルシートは、ファイル・システムの正しい場所に作成されません。たとえば、このケースでは、本来/private/html/cabo/images/cacheに作成されるIMAGES_CACHE_DIRECTORY
が、実際には/private/html/HTML/cabo/images/cacheに作成されます。最終的には、生成されたイメージおよびスタイルシートのURLが別名の付けられたディレクトリ内の場所と一致せず、イメージは損なわれ、スタイルは欠落することになります。
この問題は、UIXリソースの別名の付けられた場所のフルパスを使用してUIXを構成することにより、回避できます。次のputFullURIAndPath()
へのコールは、このケースで必要な構成を示しています。
<!-- in XML -->
<base-directory>
<full-uri>/HTML/cabo/>/full-uri>
<full-path>/private/html/cabo/</full-path>
</base-directory>
// In Java:
config.putFullURIAndPath(Configuration.BASE_DIRECTORY,
"/HTML/cabo/",
"/private/html/cabo/");
前述の相対URL構成のかわりにこの完全URL構成を使用した場合、UIXでは、動的に生成されたリソースを/private/html/cabo/の下の別名の付けられたディレクトリに正しく配置します。当然のことながら、マシンによって実際のパスは異なるため、フルパスの/private/html/cabo/はハードコードしないでください。かわりに、サーブレットAPIのServletContext.getRealPath()
を使用し、別名の付けられたディレクトリのフルパスを動的に導出できます。getRealPath()
はURLをファイル・システム・パスに変換します。別名が付けられた/private/html/ディレクトリ内のJSPから次のコードがコールされた場合、正しい構成が作成されます。
// The call to getRealPath("/") will return the root directory of the
// alias, which is "/private/html".
String realPath = servletContext.getRealPath("/");
config.putFullURIAndPath(Configuration.BASE_DIRECTORY,
"/HTML/cabo/",
realPath + "/cabo/");