テキスト・エディターやその他のエディターなどの基本ツールを使用して、カスタム・ウィジェットを作成できます。
始める前に
カスタム・ウィジェットを開発するには、以下の知識が必要です。
- Dojo 1.8.6
- Extensible Markup Language (XML)
- HyperText Markup Language (HTML)
- iWidget 2.1 の仕様
- JavaScript
開発するウィジェットの機能に応じて、以下についての知識が必要になる場合もあります。
- JavaScript と Dojo を使用しない場合は、ウィジェットのプログラミング言語またはスクリプト言語
- Java™ 2 Platform, Enterprise
Edition (J2EE)
- Representational State Transfer (REST)
手順
- カスタム・ウィジェットのファイルを入れるディレクトリー構造を作成します。
ヒント: 共通ウィジェットは、次のような構造です。iWidget/widgets/widget_name
このパスを一貫して使用するか、または独自の構造を使用することができます。
- widget_name ディレクトリーで、ウィジェット定義ファイルを作成し、その中でウィジェットを定義します。 ウィジェット定義およびその要素と、iContext に関する詳細については、iWidget 仕様を参照してください。
ヒント: ウィジェット定義ファイルの命名規則は widgetName_iWidget.xml です。
ウィジェット定義とその要素で、次のことを定義します。
- 使用するウィジェットとスキーマの名前。
以下に例を示します。
<?xml version="1.0" encoding="UTF-8" ?>
<iw:iwidget
id="HelloWorld"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:iw="http://www.ibm.com/xmlns/prod/iWidget"
supportedModes="view edit"
lang="en"
iScope="HelloWorld"
name="helloWorld">
id は固有でなければなりません。
- ウィジェット実装の Dojo ラッパー・クラスであるスコープ。
以下に例を示します。
<iw:iwidget
id="HelloWorld"
...
iScope="HelloWorld"
name="helloWorld">
iScope は、ウィジェットの動作を定義する JavaScript クラスの名前に一致している必要があります。
- ウィジェットがサポートするモードと、各モードの定義。
例えば、モードは次のように追加します。
<iw:iwidget
id="HelloWorld"
...
supportedModes="view edit"
...
name="helloWorld">
例えば、追加したモードは次のように定義します。
<iw:content mode="view">
<![CDATA[
<div>Hello World</div>
]]>
</iw:content>
何かが表示されるようにするため、view モードを定義する必要があります。ユーザーに何らかの方法でウィジェットのコンテンツを (「設定の編集」メニュー項目を使用して) 変更させたい場合は、edit モードを追加してください。 edit モードは「インスタンス」属性レイヤー内のウィジェット属性 (設定) を変更します。
特定のユーザー (一般には管理者のみ) にウィジェットのデフォルト値を変更させたい場合は、config モードを追加してください。
config モードは、「管理」レイヤー内のウィジェット属性を変更します。 ユーザーに、ウィジェットのデータ表示方法をカスタマイズさせ、その変更内容を個々のユーザーにのみ適用させたい場合は、personalize モードを追加してください。 personalize モードは、「ユーザー」レイヤー内のウィジェット属性を変更します。 属性レイヤーについては、非推奨: ウィジェット属性レイヤー および 非推奨: ウィジェット・カスタマイズ/個人設定のサポート を参照してください。
- iScope を宣言する JavaScript ファイルのパスおよび名前。 iScope は、実行時に iContext クラスへのエントリー・ポイントになる Dojo クラスです。 このエントリー・ポイントは、iContext クラスを介して環境と相互作業するウィジェットの一部です。 iContext クラスは、ウィジェット・ランタイム環境の中心であり、グローバル変数、共有状態、ローカル変数ストレージ、イベントを使用したウィジェット通信、リモート・サービス、モード・サポート、および他の数多くの機能へのアクセスといったすべての環境サービスを備えています。
例えば、次のようになります。<iw:resource src="helloWorld.js" id="iScopeFile" /> この場合、ファイルはウィジェット定義と同じディレクトリー内に置かれるため、パスを組み込む必要はありません。
- ウィジェットの属性。ユーザーが変更可能な設定を含みます。 これらの属性は、ウィジェットのデフォルト値を提供します。 値はストリングとして格納されるため、実装ではこれらの値の変換が必要になる場合があります。 以下に例を示します。
<iw:itemSet id="attributes" private="true">
<iw:item id="url" readOnly="false" value="http://www.ibm.com"/>
</iw:itemSet>
- 各イベントの定義と記述を追加することで、ウィジェットが公開して扱うイベント。 例:
<iw:event eventDescName="displayHtml" handled="true" id="Receive URL" onEvent="displayMarkup"/>
<iw:eventDescription
description="Receives and displays a URL that is sent from another widget"
id="displayHtml"
lang="en"
payloadType="url.html"
title="Receive URL">
</iw:eventDescription>
- ウィジェットで必要なその他のファイルの相対パスおよび名前を、リソースとして追加します。 例えば、ウィジェットでフォーマット設定のために .css ファイルを使用する場合は、このファイルのパスおよび名前をリソースとして追加します。
ただし、リソースを追加する際は、リソースに対する要求が多すぎるとパフォーマンスに影響すること、およびコードが参照する JavaScript、CSS、および イメージ・ファイルは可能な限り少なくすべきであることを考慮に入れてください。 ウィジェットの設計時には、イメージ・スプライト、JavaScript と CSS ファイルの結合および最小化、リソースの遅延ローディング (例えば、onEdit イベントが発生するまで edit モードのリソースのロードを待機する) などの技法を使用することを検討してください。
- iScope を宣言した JavaScript ファイルを作成してから、そのインターフェースを特定することで iScope の定義を開始します。 JavaScript または他のいずれかのプログラミング言語やスクリプトを使用して、ウィジェットの実装を作成します。 ウィジェット実装の開発と並行して iScope の開発を続けます。
ヒント: ウィジェットが単純なものであり、その実装で JavaScript を使用する場合は、iScope ファイル自体でウィジェットの実装を作成します。
- iWidget 仕様の事前定義イベントを含め、iWidget 定義で追加されたモード用に、およびインターフェースで定義された各種イベント用に、ハンドラーを作成します。 以下の事前定義 iEvent (iWidget 仕様に含まれている iEvent) については、デフォルトのイベント・ハンドラーが用意されています。デフォルトのイベント・ハンドラーは、必要に応じてオーバーライドすることもできます。
- onLoad: 初めてウィジェットをロードする時、およびブラウザーがリフレッシュされた時に呼び出されます。 ウィジェットでこのハンドラーの初期ビューを初期化できます。 イベント・ペイロードはありません。
次のようなコードを使用して、項目を取り出すことができます。
var att = this.iContext.getiWidgetAttributes();
this.name = att.getItemValue("name");
- onReload: ウィジェットが再ロードされるときに呼び出されます。 このイベント・ハンドラーは onLoad に似ていますが、やや異なる状況で呼び出されます。 ユーザーが edit モードである時に、設定ウィンドウの下部にあるいずれかのボタンを選択すると、表示モードのリフレッシュ時に onReload イベント・ハンドラーが呼び出されます。 この動作は、iWidget 仕様の呼び出しとは若干の相違があります。
iWidget 仕様では、iWidget コンテンツの edit モード・リフレッシュ中ではなく、再ロードの前に、このイベントの発生が要求されます。
イベント・ペイロードはありません。
- onUnload: ウィジェットがアンロードされようとしているときに呼び出されます。 イベント・ペイロードはありません。
重要: 作成した Dojo ウィジェットがすべて、このイベント・ハンドラーの実行中にクリーンアップされていることを確認します。 メモリー使用に関して、すべての子 Dojo ウィジェットが必ずクリーンアップされるよう
に、<widget>.destroyRecursive() を呼び出す必要があります。
- onRefreshNeeded: iContext でウィジェットのデータが不整合であると判別されたときに呼び出されます。 このイベントでは、該当する場合に、iWidget にそのデータをリフレッシュするようにシグナルが通知されます。
- ウィジェット定義の supportedModes 属性に指定された各モードに対して、モード・ハンドラーを作成します。 例えば、ウィジェットに view モードと edit モードがある場合は、onView および onEdit メソッドを作成します。
onView メソッドは次のようにコーディングできます。
onView: function(){
...
}
- onSizeChanged イベントのハンドラーを作成します。 イベントには newWidth および newHeight 属性の値を含むペイロードがあります。
ハンドラーは、この情報を使用してウィジェットのサイズを指定された幅と高さに変更します。 ユーザーがウィジェットを最小化すると、これらの属性は値 0 になります。
以下のコードは、onSizeChanged ハンドラーの使用方法を示しています。
onSizeChanged: function(iEvent) {
var data = iEvent.payload;
if (data) {
alert("new height: " + data.newHeight);
alert("new width: " + data.newWidth);
}
}
- オプション: ウィジェットが REST API を介してデータにアクセスする場合、次の例のようなコードで Uniform Resource Identifier (URI) を使用します。
dojo.xhrGet({
url: this.iContext.io.rewriteURI(uri),
load: handler
});
他の HTTP アクション (PUT、POST、DELETE) にも同様の方法を使用できます。
- カスタム・ウィジェットのプレビューおよびアイコン・イメージの役割を果たすイメージ・ファイルを作成します。 アイコン・イメージは 28 × 28 ピクセル、プレビュー・イメージは 160 ピクセル幅× 128 ピクセル高にする必要があります。
- オプション: カスタム・ウィジェットにオンライン・ヘルプがある場合は、1 つ以上の HTML ファイルを作成して、ヘルプ・テキストを指定します。 これらのファイルをウィジェットを使用してパッケージ化するか、文書プラグインを作成してヘルプ・ファイルをそのプラグインに組み込むことができます。 詳しくは、『非推奨: 文書プラグインの作成』を参照してください。
- ウィジェット定義ファイル、ウィジェット実装ファイル、およびイメージ・ファイルを、適切なパッケージ化ツールを使用して EAR にパッケージ化します。 このツールでは、J2EE 仕様に応じて EAR および WAR にパッケージ化できなければなりません。
- カスタム・ウィジェットを登録するには、カタログ・ファイルにウィジェットの定義を作成します。 項目は、既存のカタログ・ファイルに置くことも、固有のカタログ・ファイルを作成してその中に置くこともできます。
カタログ・ファイルおよびウィジェット登録定義の作成については、非推奨: カタログ・ファイルを使用したカスタム・ウィジェットの登録 を参照してください。
ヒント: ウィジェット登録ファイルの命名規則は catalog_catalogName.xml です。
- 非推奨: カスタム・ウィジェットのパッケージ化およびデプロイ の説明に従って、カスタム・ウィジェットをパッケージ化し、デプロイします。
- Web ブラウザーで、ダッシュボードの URL をブラウズします。 この URL は、次のようなものです。http://localhost:9080/BusinessSpace