Oracle ADF UIX開発者ガイド | ![]() 目次 |
![]() 前へ |
![]() 次へ |
このトピックでは、UIXのイメージ生成テクノロジであるOracle ADF UIX Dynamic Imagesにより提供される、イメージ生成機能について説明します。 ここでは、次の項目について説明します。
UIX ComponentsおよびUIX XMLによってレンダリングされるHTMLコンテンツには、通常、HTMLの<img>
要素を介して指定されるイメージがいくつか含まれています。 イメージの使用は一般的ですが、UIXのコア・レンダリング・テクノロジでは、イメージは必要ではありません。 つまり、UIX Componentsの特定のRenderer
の実装では、イメージを使用し、生成される出力の外観を改善するためイメージの使用が選択される場合がありますが、これは必須ではありません。 たとえば、UIX Componentsのブラウザ・ルック・アンド・フィールのRenderer
の実装では、ボタンおよびタブ・バーなどのいくつかのユーザー・インタフェース・コンポーネントの実装にイメージを使用します。 これらのユーザー・インタフェース・コンポーネントは、イメージではなく単純なテキスト・リンクを使用して、クライアント・アプリケーション・コードに影響を与えずに別のRenderer
によって実装できます。
イメージは、グラフィック情報の表示、またはWebページの外観を改善するツールとして広く使用されていますが、イメージの使用には、アプリケーション開発者が考慮する必要のある問題がいくつかあります。 たとえば、テキストを含むイメージ(ButtonBean
のブラウザ・ルック・アンド・フィールの実装など)は、翻訳が非常に困難です。 このようなイメージは、翻訳に余分な時間およびリソースを割り当てる必要があるため、国際化アプリケーションの開発における障害になります。 カスタマイズされたフォント、色またはテキストを含むイメージを手動で作成するのは時間がかかるため、一般に、イメージのカスタマイズも難しくなります。 必要なイメージに対してエンド・ユーザーの指定フォントおよび色を使用できない場合があるため、結果的には、イメージはパーソナライズの障害になります。
これらイメージ関連の問題を解決する方法の1つは、単にイメージを使用しないことです。 UIX Componentsでは、イメージに依存しないRenderer
の実装の使用を選択することで、この解決方法を容易に実行できます。 しかし、ほとんどのアプリケーションはイメージを利用するため、UIXには、これらのアプリケーションが直面するローカライズ、カスタマイズ、およびパーソナライズの問題に対する解決方法が用意されています。 UIXには、これらの問題に対する解決方法は、UIX Dynamic Imagesのイメージ生成フレームワークにより提供されます。
UIX Dynamic Imagesでは、デプロイメント前にイメージを静的に生成する機能、またはWebアプリケーションの実行時に動的に生成する機能を提供しています。 UIX Dynamic ImagesのImageGenerator
ツールでは、翻訳されるテキストを含むイメージおよびメッセージ・ファイルのXMLの記述に基づいて、ボタンおよびタブ・バーなどのイメージを生成します。 静的イメージ生成は、手動によるイメージ作成より効率的ですが、必要なイメージすべてをアプリケーションのデプロイ前に生成する必要があるため、単調で時間を要する方法です。 イメージ生成プロセスを単純化するために、UIX Dynamic Imagesでは、ImageProvider
インタフェースを介した動的生成もサポートしています。 実行時に、アプリケーションからImageProvider
の実装にリクエストを送り、必要に応じてImageProvider
で新規イメージを生成します。 UIX ComponentsまたはUIXベースのアプリケーションでは、UIX Dynamic Images固有のコードを作成せずに、UIX Dynamic Imagesの動的イメージ生成を利用できます。 たとえば、UIX Componentsのブラウザ・ルック・アンド・フィールのButtonRenderer
クラスおよびTabBarRenderer
クラスでは、UIX Dynamic ImagesのImageProvider
に、必要なイメージに対するリクエストを自動的に送ります。 UIX Dynamic Imagesが特定のUIX ComponentsのRenderer
の実装で使用されることは、アプリケーション・コードに対して完全に透過的です。
UIX Dynamic Imagesにより、イメージの使用により生じるローカライズ、カスタマイズ、およびパーソナライズの問題は解決されますが、この方法はコストがかかります。 UIX Dynamic Imagesには、JavaのAWTグラフィック・ライブラリで提供されるグラフィック機能が必要です。 かわりに、AWTでは、基本プラットフォームにより提供されるグラフィック・サポートを利用します。 このように、UIX Dynamic Imagesでは、グラフィック機能が使用可能な環境でのイメージ生成のみを行います。 たとえば、UNIX環境では、AWTのグラフィック・ニーズの対応にXサーバーが必要です(JDK 1.4以前の環境の場合)。 これは、ほとんどの中間層環境に対する最新の要件であるため、システム管理を行い、実行時環境がAWTのグラフィック要件を満たすよう正しく構成されているかを何度も確認する必要があります。 デプロイメント環境がグラフィック操作を想定して構成されているとはかぎらないため、UIX Dynamic Imagesでは、リモート・マシンにイメージ生成をオフロードすることを可能にするUIX Dynamic Imagesサーブレットなど、この要件を軽減するオプションを提供しています。
ソフトウェア・アプリケーションの翻訳における基本作業の1つは、アプリケーション・ユーザー向けのメッセージのローカライズです。 この作業を効果的に行うため、アプリケーション開発者は翻訳可能なメッセージすべてをメッセージ・ファイルに保存し、翻訳チームに渡します。 アプリケーションに翻訳の必要があるイメージが含まれている場合は、別に処理します。 GIFなどのイメージ・ファイル形式では、テキスト・メッセージは、外部化された翻訳可能な形式では格納されていません。 イメージを翻訳する際、翻訳者はイメージ操作ツールを使用してイメージを表示し、翻訳対象のテキストを検出する必要があります。 テキストの翻訳後、翻訳済テキストを含む新規イメージの作成が必要です。 翻訳済イメージの手動作成にはグラフィック・デザイン・スキルが必要で、時間も非常にかかります。 したがって、翻訳チームでイメージ・ファイルの翻訳が可能であるにもかかわらず、イメージ翻訳プロセスでは翻訳チームのリソースが非効率的に使用されることになります。
UIX Dynamic Imagesの目的の1つは、翻訳済イメージの手動作成といった、翻訳プロセスで時間を要するステップを自動化することで、イメージ翻訳プロセスを単純化することにあります。 UIX Dynamic ImagesのImageGenerator
ツールでは、イメージの記述に基づいて、ボタンおよびタブ・バーのイメージなどのイメージ・ベースのユーザー・インタフェース・コンポーネントを生成します。 イメージは、UIX Dynamic Imagesで定義されているXML言語であるImageGenerator XML言語を使用して記述されます。 ImageGenerator XML文書は、コマンドライン引数としてImageGeneratorツールに渡されます。 ImageGeneratorツールでは、指定されたXML入力ファイルを解析し、文書の各エントリに対するタイプおよびプロパティを判別して、要求された各イメージのGIFイメージ・ファイルを作成します。
次のImageGenerator XMLサンプル文書は、単一イメージの記述です。
<?xml version="1.0"?>
<ImageGenerator>
<button name="login">
<text>Login</text>
</button>
</ImageGenerator>
</pre>
<button>
要素は、ボタンを含むイメージが生成されることを示します。 (ボタンのラベル「Login
」は、<button>
要素の<text>
子要素を介して指定します。 ボタン・イメージは次のコマンドラインで生成されます(記述はsample.xml
という名前のファイルに格納されています)。
java oracle.cabo.image.tools.ImageGenerator sample.xml
その結果、login.gif
という名前の次のボタンが作成されます。
UIX Dynamic ImagesのImageGeneratorツールでイメージを作成すると、イメージをWebサーバーにインストールし、HTMLの<img>
要素を介してアプリケーションからアクセスできます。
ボタン以外に、UIX Dynamic Imagesにはグローバル・ボタン、色付きアイコンおよびタブ・バーという3つのイメージ・タイプを生成するビルトイン・サポートが含まれています。
グローバル・ボタンとは円形のアイコン・ボタンで、通常はWebページの最上部に配置され、グローバル・アプリケーション機能へのアクセスを提供します。 たとえば、グローバル・ボタンは、一般的にはヘルプ・システムまたはログイン・サービスなどのサービスへのアクセスを提供するために使用されます。 UIX Dynamic Imagesでは、グローバル・ボタンを境界線のないグレー・スケールのソース・アイコンから生成します。 イメージの生成中に、ソース・アイコンに円形の境界線が付けられ、グローバル・ボタンの使用不可状態および選択済状態に基づいて色付けされます。 次のImageGenerator XMLファイルの記述には、使用可グローバル・ボタン、使用不可グローバル・ボタン、および選択済グローバル・ボタンの3つのエントリが存在します。
<?xml version="1.0"?>
<ImageGenerator>
<!-- An enabled help button -->
<globalButton name="help-enabled" source="help.gif"/>
<!-- A disabled help button -->
<globalButton name="help-disabled" source="help.gif" disabled="true"/>
<!-- A selected help button -->
<globalButton name="help-selected" source="help.gif" selected="true"/>
</ImageGenerator>
ソース・アイコン(Help.gif
)は次のようになります。
次に、ソース・アイコンから生成されたグローバル・アイコンを示します。
使用可ボタン
使用不可ボタン
選択済ボタン
色付きアイコンの生成は、ソース・アイコンに単純な変換が適用されるという点で、グローバル・ボタンの生成に似ています。 色付きアイコンの場合、変換は単純で、ソース・アイコンの色がカラー・スキームに従って変更されます。 一般的に、色付けは、アプリケーションのユーザー・インタフェースの部品の実装に使用されるイメージに適用されます。 たとえば、Oracle Browser Look and Feelでは、UIX ComponentsのFooterBean
のレンダリングの際に、次の3つのイメージを使用します。
左フッター・アイコン
中央フッター・アイコン
右フッター・アイコン
デフォルトのカラー・スキームでは、フッターやグローバル・ヘッダーなどのページ・レベルのコンポーネントは、青の背景色で描画されます。 これらのコンポーネントの色を変更するには、コンポーネントの実装に使用されているイメージを再度色付けする必要があります。 次のImageGenerator XML文書には、3つのフッター・アイコンに対する色付きアイコンのエントリが含まれています。
<?xml version="1.0"?>
<ImageGenerator>
<colorizedIcon name="footr" source="footr.gif"/>
<colorizedIcon name="footm" source="footm.gif"/>
<colorizedIcon name="footl" source="footl.gif"/>
</ImageGenerator>
この文書を使用してImageGeneratorを実行すると、異なるカラー・スキームに色が調整された新規バージョンのアイコンを作成できます。 次に例を示します。
タブ・バーは主要なナビゲーション・コンポーネントで、一般的に、Webページの最上部に配置されます。 次のイメージは、3つのタブを含むタブ・バーを示しています。
タブ・バー・イメージは、UIX Dynamic ImagesのImageGeneratorでImageGenerator XML要素の<tabBar>
を使用して生成されます。 次のサンプルXMLコードは、上に示したタブ・バーの記述です。
<?xml version="1.0"?>
<ImageGenerator>
<tabBar name="tabs" selectedIndex="1">
<tab>
<text>First Tab</text>
</tab>
<tab>
<text>Second Tab</text>
</tab>
<tab>
<text>Third Tab</text>
</tab>
</tabBar>
</ImageGenerator>
タブ・バー・イメージの生成に加えて、ImageGeneratorでは、タブ・バーのHTMLイメージ・マップも生成します。 イメージ・マップは、生成されるイメージと同じ名前で .map
ファイルに格納されます。 タブ・バーの各リンクのURLは、ImageGenerator XML文書で各<tab>
要素のdestination
属性を介して指定します。
4つの事前定義済イメージ・タイプのうち、ボタン・イメージおよびタブ・バー・イメージのみが翻訳対象として考えられます。 色付きアイコンが翻訳されることはありません。 グローバル・ボタンのソース・アイコンは別のロケールに合せてカスタマイズされますが、グローバル・ボタンには翻訳可能なテキストは存在せず、メッセージ翻訳プロセスには含まれません。
UIX Dynamic ImagesのImageGeneratorツールを使用してボタン・イメージおよびタブ・バー・イメージの翻訳済バージョンを生成するには、すべてのボタンおよびタブ・バーのエントリを含むImageGenerator XML文書を作成する必要があります。 通常、ImageGenerator XML文書の作成はアプリケーション開発チームの作業であり、翻訳チームの作業ではありません。 ImageGenerator XML文書が作成されると、ローカライズのため、翻訳チームに渡されます。 翻訳チームは、各<text>
要素がターゲット・ロケールに合せて翻訳された、ImageGenerator XML文書のロケール固有の新規翻訳を作成します。 例として、次に、日本語に翻訳された後の「Login」ボタンのサンプル文書を示します。
<?xml version="1.0"?>
<ImageGenerator>
<button name="login">
<text>争亊事</text>
</button>
</ImageGenerator>
<text>
要素が、「Login」から、エスケープUnicode文字列としてエンコードされた日本語の文字列に翻訳されています。 ImageGeneratorが翻訳済文書で実行されると、次の翻訳済イメージが作成されます。
ImageGenerator XML文書は翻訳が非常に容易ですが、ImageGenerator XMLは標準のメッセージ・ファイル形式ではありません。 そのため、翻訳チームはこの新規XML言語の処理を必ずしも得意としない場合があります。 理想的には、イメージ関連の翻訳であることを翻訳チームに意識させない必要があります。 つまり、翻訳者の視点からは、イメージの翻訳メッセージと、他のアプリケーション・コンテンツの翻訳メッセージに違いがないようにします。 UIX Dynamic Imagesでは、最も一般的に使用されているJavaメッセージ・ファイル形式のJava ResourceBundleを使用することにより、この解決方法を実行します。
翻訳を容易にするため、アプリケーション・コードから翻訳対象メッセージを分離する場合と同様に、ImageGenerator XML文書からも翻訳対象メッセージを分離できます。 <text>
要素のかわりに<translatedText>
要素を使用し、実際のテキスト文字列をJava ResourceBundleから取得することを示します。 次のサンプルでは、<translatedText>
要素を使用するよう変更された「Login」ボタン文書の新規バージョンを示します。
<?xml version="1.0"?>
<ImageGenerator>
<defaults>
<!-- The ResourceBundle name -->
<bundle>SampleBundle</bundle>
<!-- The locales to generate: English, French and Japanese -->
<locale language="en"/>
<locale language="fr"/>
<locale language="ja"/>
</defaults>
<button name="login">
<translatedText key="LOGIN"/>
</button>
</ImageGenerator>
文書は次の3つの点について変更されています。 まず、<text>
要素が、ResourceBundleの翻訳済メッセージの検索に使用するキーを指定する<translatedText>
要素に置き換えられています。 次に、<bundle>
要素が<defaults>セクションに追加されています。 この要素では、使用するResourceBundleの完全修飾Javaクラス名を指定します。 最後に、いくつかの<locale>要素が<defaults>
セクションに追加されています。 ロケール固有のResourceBundleを使用して、各<locale>
要素についてイメージのセットが生成されます。 生成されたイメージの各セットは、個別のロケール固有の出力ディレクトリに配置されます。
文書でImageGeneratorを実行する前に、各ロケールのResourceBundleを作成し、コンパイルする必要があります。 アプリケーション開発チームが、ベース・ロケール(英語)のResourceBundleを作成します。 次の例では、ResourceBundleにはLOGIN
キーに対応する単一メッセージのみが必要です。 これは、標準のJava ListResourceBundle
として実装できます。
import java.util.ListResourceBundle;
public class SampleBundle extends ListResourceBundle
{
public Object[][] getContents()
{
return contents;
}
static final Object[][] contents =
{
{"LOGIN", "Login"},
};
}
ベースのResourceBundle
は翻訳チームに渡され、そこで、各ロケールにローカライズしたバンドルを作成します。 バンドルが翻訳されコンパイルされると、イメージの翻訳済バージョンがImageGeneratorで生成されます。
UIX Dynamic ImagesのImageGeneratorによる静的イメージ生成は、手動による翻訳済イメージの作成を不要にすることにより、イメージ翻訳プロセスを単純化します。 しかし、この新規アプローチにはいくつかの障害があります。 次に例を示します。
このような障害の回避策として、UIX Dynamic Imagesでは、動的イメージ生成をサポートしています。 動的イメージ生成により、アプリケーションでは、必要なイメージを実行時に要求できます。 必要なイメージが使用可能でない場合は、UIX Dynamic Imagesにより生成されます。 これは、アプリケーションで使用するイメージのセットをあらかじめ定義しておく必要がないことを意味します。 イメージを生成するステップが1つも存在しないため、ImageGenerator XML文書は必要ありません。 必要に応じてイメージが作成されるため、ローカライズされたメッセージや、カスタマイズまたはパーソナライズされた色およびフォントで、イメージが動的に生成されます。
動的イメージ生成リクエストは、ImageProvider API
を介してUIX Dynamic Imagesに送られます。 ImageProvider
インタフェースは、1つのメソッドgetImage()
を定義します。 getImage()メソッドを介して、リクエストされたイメージの情報がアプリケーションからImageProviderに渡されます。 ImageProvider
では、要件を満たすイメージが使用可能であるかどうかを判断して、リクエストに応答します。 そのようなイメージが存在しない場合、要件を満たす新規イメージがImageProvider
により作成されます。 その後、ImageProvider
では、URLで使用するイメージの位置など、生成されたイメージについての情報を返します。
ImageProvider.getImage()
メソッドは、次のように定義されます。
public ImageProviderResponse getImage(
ImageContext context,
ImageProviderRequest request
);
ImageContext
は、UIX ComponentsのRenderingContext
に類似しています。 ImageProvider
はImageContext
を使用して、エンド・ユーザーのロケールなど、エンド・ユーザーの環境に関する情報を取得します。 ImageContext
では、ErrorLog
オブジェクトおよびConfiguration
オブジェクトなどのグローバル・コンテキスト・オブジェクトへのアクセスも提供します。 UIX Dynamic Imagesでは、1つのImageContext
の実装のImageContextImpl
を提供します。 UIX ComponentsのRenderingContext
インスタンスのように、UIX Dynamic ImagesのImageContext
インスタンスは、1つのHTTPリクエストについての情報をカプセル化します。 そのため、UIX Dynamic Imagesクライアントは、1つのHTTPリクエストの処理中に、1つのImageContext
インスタンスをgetImage()
へのすべてのコールに使用できます。 ただし、ImageContext
インスタンスは、複数のHTTPリクエストにまたがって再利用することはできません。
ImageProviderRequest
では、必要な特定のイメージを定義するタイプ固有のプロパティ・セットと、生成するイメージのタイプ(ボタン、タブ・バーなど)の両方を指定します。 イメージ・タイプは、ネームスペースおよびローカル名の両方で指定されます。 イメージ・タイプはネームスペースによってパーティション化されるため、クライアントでは、事前定義済イメージ・タイプ名と競合せずに、カスタム・イメージ・タイプを定義できます。 事前定義済イメージ・タイプの1つであるイメージをリクエストする場合、ImageConstants.TECATE_NAMESPACE
で定義されるUIX Dynamic Imagesのネームスペースを使用します。 UIX Dynamic Imagesの4つの組込みイメージ・タイプに対する名前定数は、ImageConstants
インタフェースのBUTTON_NAME
、GLOBAL_BUTTON_NAME
、COLORIZED_ICON_NAME
およびTAB_BAR_NAME
によって定義されます。
ImageProviderRequestsは、getRenderProperites()
メソッドを介して、要求されたイメージのプロパティの情報を提供します。 このメソッドでは、要求されたイメージのプロパティを含むjava.util.Dictionary
オブジェクトを返します。 要求されたプロパティのキーは、ImageConstants
インタフェースで定義されます。 プロパティ値は、タイプ固有です。 たとえば、ImageConstants.TEXT_KEY
を使用して、ボタン・イメージのString
テキスト・ラベルを指定します。 ImageConstants.FOREGROUND_KEY
では、ボタンのテキスト・ラベルのレンダリングに使用するjava.awt.Color
前景色の値を定義します。 ImageProviderRequestImpl
は、イメージ・プロパティの任意のDictionary
をラップするImageProviderRequest
の汎用実装です。
次のサンプル・コードでは、ImageProviderから「Login
」ボタンを要求する方法を示します。
// Create the ImageContextImpl with the end user's locale, direction
// and the current ErrorLog.
ImageContextImpl context = new ImageContextImpl(localeContext,
agent,
colorScheme,
errorLog,
config);
// Create the dictionary of request properties. Since we only need
// a very small dictionary, we use oracle.bali.share.collection.ArrayMap
// instead of java.util.Hashtable.
ArrayMap properties = new ArrayMap(1);
properties.put(ImageConstants.TEXT_KEY, "Login");
// Create the ImageProviderRequest
ImageProviderRequest request = new ImageProviderRequestImpl(
ImageConstants.TECATE_NAMESPACE,
ImageConstants.BUTTON_NAME,
properties);
// Make the request to the ImageProvider
ImageProviderResponse response = imageProvider.getImage(context, request);
if (response != null)
{
// Render an img element using the location in the ImageProviderResponse
}
ImageProvider.getImage()
から返されるImageProviderResponse
オブジェクトには、要求されたイメージに対するHTMLの<img>
要素をアプリケーションで生成するために必要な情報がすべて含まれています。 ImageProviderResponse.getImageURI()
はイメージの位置を返し、返された位置は、ベースURIを付加した後に、<img>
要素のsrc
属性の値として使用できます。 生成されたイメージの幅および高さも、ImageProviderResponse
を介してレポートされます。 次に、この値は<img>
要素のwidth
属性およびheight
属性として指定され、ブラウザによる効率的なページ・レイアウトに利用されます。 最後に、タブ・バーなどのコンポジット・コンポーネントに対して、ImageProviderResponse
で個々のコンポーネント・リージョンの位置およびサイズについての情報を提供できます。 この情報は、イメージのHTMLイメージ・マップを生成するために、アプリケーションで使用できます。
UIX Dynamic Imagesでは、1つのImageProvider
の実装のFileSystemImageCache
を提供します。 FileSystemImageCache
ではその名のとおり、生成するイメージの格納メカニズムとしてファイル・システムを使用します。 イメージのキャッシュのルート・ディレクトリは、FileSystemImageCache
インスタンスの作成時に指定されます。 FileSystemImageCache
によって生成されるすべてのイメージは、このディレクトリの下に格納されます。
URLを介してイメージにアクセスするには、イメージ・キャッシュのルート・ディレクトリをWebサーバーを介してアクセスできる場所にする必要があります。 たとえば、イメージ・キャッシュをWebサーバーのドキュメント・ルートの下、またはWebサーバーでアクセスできる他の別名ディレクトリの下に配置します。 FileSystemImageCache
によって返されるURIは、常にキャッシュのルート・ディレクトリに対して相対的です。 そのため、HTMLの<img>
要素のソースとして使用する完全なURLを生成するには、返されたURIにベースURIを付加します。 たとえば、Webサーバーのドキュメント・ルートがD:\Apache\htdocs
にあり、イメージ・キャッシュのルート・ディレクトリがD:\Apache\htdocs\images\cache
である場合、アプリケーションでは、ベースURIの/images/cache/
にFileSystemImageCache
から返されたURIを付加します。
イメージ・キャッシュは著しい量のメモリー・リソースおよびディスク・リソースを使用するため、FileSystemImageCache
インスタンスは、同じJava Virtual Machineで実行されているすべてのアプリケーション間で共有されます。 共有されているFileSystemImageCache
インスタンスは、イメージ・キャッシュのルート・ディレクトリを唯一の引数とするFileSystemImageCache.getSharedCache()
メソッドを介して取得できます。 FileSystemImageCache
の1つの共有インスタンスは、一意のルート・ディレクトリごとに作成されます。 次のサンプルでは、FileSystemImageCache
の取得方法を示します。
FileSystemImageCache cache = FileSystemImageCache.getSharedCache(
"D:\Apache\htdocs\images\cache");
実際のアプリケーションでは、ハードコードされたルート・ディレクトリは使用しないので注意してください。 使用する実際のディレクトリは、アプリケーションがインストールされているマシンのディレクトリ構造に完全に依存します。 たとえば、URI /images/cache
に対応するディレクトリは、/private/tomcat/webapps/root/images/cache
であったり、他のディレクトリである場合もあります。 イメージ・キャッシュのルート・ディレクトリに固定値を使用するかわりに、ユーザーがアプリケーションのインストール時にこの情報を指定できるようにするか、アプリケーションのインストール後に値を構成できるようにする必要があります。 また、ディレクトリはサーブレットAPIを使用して動的に導出することもできます。 ServletRequest.getRealPath()
メソッドを使用して、URLをファイル・システムでのパスに変換します。 したがって、前述の例は、次のように実装するとより効率的です。
FileSystemImageCache cache = FileSystemImageCache.getSharedCache(
request.getRealPath("/images/cache"));
このようにgetRealPath()
を使用すると、ディレクトリが特定のターゲット・マシンのどこに配置されるかにかかわらず、URLの/images/cache
に対応するWebサーバー・ディレクトリにイメージ・キャッシュが作成されます。
FileSystemImageCache
インスタンスが初めて作成される際に、既存のイメージがルート・キャッシュ・ディレクトリで検索されます。 FileSystemImageCache
により、イメージ・タイプ、位置およびプロパティなどの各イメージの情報がメモリー内キャッシュにロードされます。 特定のイメージがFileSystemImageCache
に要求されると、FileSystemImageCache
では、まず、イメージの情報がメモリー内キャッシュで使用可能であるかどうかを調べます。 メモリー内キャッシュで一致が検出された場合、イメージ情報とともにImageProviderResponse
が返されます。
FileSystemImageCache
で要求を満たすイメージを検出できない場合は、いくつかのステップが実行されます。 まず、要求されたイメージが、ImageRenderer
インタフェースのインスタンスを使用して、メモリーに作成されます。 ImageRenderer
により、ImageProviderRequest
で指定した要求されたプロパティのDictionary
に基づいて、java.awt.Image
インスタンスが生成されます。 AWT Image
が作成されると、データが取得され、キャッシュ・ディレクトリの下にあるイメージ・ファイルに保存されます。 エントリがメモリー内キャッシュに追加されるため、同じイメージの要求は早く処理されます。 イメージ・データをファイル・システムに保存するのみでなく、関連するメタデータ・ファイルが各イメージに対して作成されます。 メタデータ・ファイルには対応するイメージの完全な記述が格納され、特定のイメージ・インスタンス(ボタンのラベル、色、フォントなど)を定義するすべてのプロパティと同様に、イメージのタイプ(ボタン、タブ・バーなど)が含まれます。
次の例では、「Login
」ボタン・イメージに対応するメタデータ・ファイルの内容を示します。
<?xml version="1.0" encoding="UTF-8"?>
<ImageMetadata version="0.1">
<button width="59" height="26" direction="ltr" renderer="oracle.cabo.image.laf.browser.ButtonImageRenderer">
<foreground red="0" green="0" blue="0"/>
<background red="247" green="247" blue="231"/>
<font>
<name>dialog</name>
<size>12</size>
<style>plain</style>
</font>
<colorScheme namespace="http://www.example.org/myColorSchemeNS" name="default"/>
<text>Login</text>
</button>
</ImageMetadata>
イメージ・メタデータに使用するXML言語は、ImageGenerator XML言語とほぼ同じです。 イメージ・メタデータ・ファイルは、対応するイメージと同じファイル名を共有します。 拡張子 .imx
(ImageMetadata XMLの短縮形)が、イメージ・メタデータ・ファイルに使用されます。
イメージおよびそのメタデータは、作成されキャッシュされると、FileSystemImageCache
に永久に保持されます。 つまり、イメージがキャッシュされると、イメージは、サーブレット・エンジン・セッション間で永続します。 サーブレット・エンジンが停止した後でも、すべてのイメージおよび対応するメタデータが、ファイル・システムにキャッシュされた状態で保持されます。 サーブレット・エンジンの再起動時には、ファイル・システムに格納されているイメージ・ファイルおよびメタデータ・ファイルに基づいて、FileSystemImageCache
によりメモリー内キャッシュが再度初期化されます。
イメージ生成は、当初、イメージ翻訳の問題を解決するために立案されました。 静的イメージ生成により、負荷が翻訳チームからアプリケーション開発チームに移り、開発チームでImageGenerator XMLファイルをメンテナンスし、生成および統合作業を実行します。 動的イメージ生成では、UIX Dynamic ImagesのImageProvider
APIに対してコーディングすることで、アプリケーション開発チームをこれらの作業から解放します。 その結果、イメージ翻訳の問題はすべて解消されます。
UIX Dynamic Imagesベースのアプリケーションで、ボタン・イメージまたはタブ・バー・イメージがImageProvider
に要求されると、アプリケーションでは翻訳済メッセージをImageProvider
に渡す必要があります。 たとえば、ボタン・イメージが要求された場合、ボタンのラベルは、ImageConstants.TEXT_KEY
を使用してアプリケーションで指定されます。 イメージの翻訳済バージョンが自動的に生成およびキャッシュされ、翻訳済イメージの場所がアプリケーションに返されます。 UIX Dynamic Imagesでは、アプリケーションで翻訳済メッセージを取得する方法に制限はありません。 ImageGenerator XML文書は不要です。 任意のメッセージ・ファイル形式または翻訳リポジトリを使用できます。 翻訳後の生成または統合作業は必要ありません。 その結果、イメージ翻訳プロセスは、アプリケーションの残りの内容に対する翻訳プロセスと同じになり、場合によっては統合できます。
イメージ翻訳は、ロケール固有のメッセージをImageProvider
に渡すという単純な処理になります。 同じように、カスタマイズまたはパーソナライズした色およびフォントをイメージの要求時に指定するのみで、イメージをカスタマイズおよびパーソナライズできます。 UIX Dynamic ImagesのImageConstants
インタフェースでは、生成されたイメージの外観を制御するために使用するいくつかのプロパティ(FONT_KEY
、BACKGROUND_KEY
およびFOREGROUND_KEY
を含む)を定義します。 メッセージ翻訳の場合と同様に、ImageProvider
では、アプリケーションでフォントおよび色を決定する方法に制限はありません。 アプリケーションでは、適合するカスタマイズ方法およびパーソナライズ方法を実行できます。
動的イメージ生成では、最小限の操作で、アプリケーションにローカライズ済イメージ、カスタマイズ済イメージ、およびパーソナライズ済イメージを取り込むことができます。 ただし、UIXではさらに容易な解決方法が用意されています。 UIX Dynamic ImagesのAPIに対してコーディングするかわりに、アプリケーションでは、イメージ生成をUIXのHTMLレンダリング・テクノロジであるUIX ComponentsおよびUIX XMLに依存できます。
次のUIXコードでは、ボタン・イメージがHTMLの<img>
要素として生成およびレンダリングされます。
<button xmlns="http://xmlns.oracle.com/uix/ui" text="Login"/>
同様に、UIX ComponentsのAPIに対して直接コーディングされているクライアントは、次のコードを使用して、イメージ・ベースのボタンをレンダリングできます。
ButtonBean button = new ButtonBean("Login");
button.render(renderingContext);
ButtonBean
のブラウザ・ルック・アンド・フィールのButtonRenderer
の実装では、動的イメージ生成を利用してボタンをレンダリングします。 ButtonRenderer
では、レンダリングのためにコールされると、次のステップを実行します。 まず、ImageProvider
がUIX ComponentsのRenderingContext
から取得されます。 デフォルトでは、FileSystemImageCache
インスタンスが使用されます。 ImageConstants.IMAGE_PROVIDER_PROPERTY
をUIX ComponentsのRenderingContext
に設定することにより、アプリケーションでは固有のImageProvider
を提供できます。 デフォルトでは、イメージ・キャッシュがURIの"/cabo/images/cache"に対応するディレクトリに作成されます。 イメージ・キャッシュのルート・ディレクトリの位置は、UIX Share Configuration APIのConfiguration.IMAGES_CACHE_DIRECTORY
プロパティを介して構成できます。
次に、ButtonRenderer
では、ButtonBean
の属性値に基づいて要求されたイメージ・プロパティのDictionary
を作成することで、ImageProviderRequest
を準備します。 続いてRenderingContext.getImageContext()
メソッドから取得されるImageContext
を使用して、イメージがImageProvider
から要求されます。 ImageProvider
への要求が正常に行われた場合、ButtonRenderer
では、イメージの幅、高さ、代替テキストなどのレンダリング属性も含め、ボタン・イメージの適切なHTMLが生成されます。 タブ・バーの場合は、UIX Componentsでは、タブ・バー・リンクの実装に使用されるイメージ・マップもレンダリングします。
ButtonRenderer
では、動的イメージ生成の失敗も処理します。 要求されたイメージを生成できない場合、ButtonRenderer
は、リンク、<input>
要素、または<button>
要素などの、イメージ以外のコンテンツを生成します。
UIX Dynamic Imagesのイメージ生成フレームワークでは、Webページでのイメージ使用に関連するローカライズ、カスタマイズ、およびパーソナライズの問題に対する解決方法を提供しています。 UIX Dynamic Imagesは、静的イメージ翻訳に関連する余分なオーバーヘッドを削減します。 動的イメージ生成の使用がアプリケーション開発者には意識されないような、UIX ComponentsまたはUIXなどの高水準のレンダリング・テクノロジを使用することで、開発コストを最小限に抑えられます。 しかし、これらを利用するには、いくつかの新規要件を満たしている必要があります。
UIX Dynamic Imagesでは、生成されたイメージのコンテンツのレンダリングに、Java 2DグラフィックAPIを使用します。 Java 2Dは、グラフィック・プリミティブとテキストの両方のエイリアシング除去など、拡張グラフィック機能を提供します。 また、Java 2では、多言語アプリケーションでのイメージ生成において重要となるフォント処理のサポートが改善されています。 Java 2D APIはJava 2 Platformの一部であるため、UIX Dynamic Imagesのイメージ生成は、JDK 1.1環境では機能しません。 Java 2 Runtime Environmentが必要です。
AWTでは、イメージの作成にUIX Dynamic Imagesで必要な低レベルのグラフィック機能を提供します。 AWTは、JDK 1.0以上、コアJavaプラットフォームの一部です。 UIX Dynamic Imagesは、AWTをサポートしない実行時環境では実行できません。
Java 2 v1.4より前のリリースでは、UNIXのAWT実装でグラフィック操作を行うにはXサーバーへのアクセスが必要でした。 Java 2 v1.4では、新しくヘッドレスJava機能が導入されました。この機能を使用すると、Xサーバーへのアクセスを必要とすることなく、(イメージ生成などの)AWT操作を実行できます。 UIXベースのアプリケーションをUNIX環境にデプロイする場合、UIXユーザーは、Xサーバーの構成に関する問題を回避するため、Javaのヘッドレス・サポートを利用することをお薦めします。 ヘッドレス操作を使用可にするには、JVMの起動時に次のシステム・プロパティを指定します。
-Djava.awt.headless=true
Java 2 v1.4を使用できない環境では、イメージ生成にはXサーバーが必要です。 このような環境では、AWTがXサーバーの検索およびXサーバーへの接続を行えるようにDISPLAY環境変数を設定する必要があります。
ボタンおよびタブ・バーなどのテキストを含むイメージの生成では、テキストのラスター化にフォントを使用する必要があります。 オラクル社では、多言語イメージ生成に使用できるOracle9iAS製品で国際化フォントを提供しています。
生成されたイメージをURLを介して参照できる場所に保存するため、FileSystemImageCache
にはWebサーバーのディレクトリに対する書込みアクセスが必要です。 このディレクトリには、アプリケーションで生成されるイメージすべてを十分格納できるディスク領域が必要です。
Copyright © 2001, 2004, Oracle Corporation.
All rights reserved.