W3C XForms (この語は単数形でもあり、複数形でもある) はHTMLフォームを拡張したもので、より機能の豊富な、より動的なフォームをHTML文書に提供します。またXFormsを利用すれば、Webフォームをよりすばやく簡単に作成できます。XFormsはXML文書のように、多数のデバイスや構造化フォーム・データをサポートします。さらに開発者はXFormsを使って、スクリプトを使用せずに動的Webフォームを生成し、同じページに複数のフォームを含めたり、データにさまざまな方法で制約を加えることができます。最後に、XFormsの各部分 (つまりデータ・モデル、ビュー、コントローラー) は完全に独立しているので他のテクノロジーとともに使用できます。これらの各部分はアプリケーションに効果的に統合でき、大きな付加価値が生み出されます。
この入門記事では、XFormsの非常に役立つ機能をいくつかご紹介し、簡単なアプリケーションの例について見ていきます。この記事は2002年に発表されたXForms 1.0ワーキング・ドラフトに基づいています (参考文献には、これを含めたさまざまなリンクが提供されています)。
XFormsに取り入れられている概念の一部は、Standardized General Markup Language (SGML) に由来しています。SGMLの目的の一つは、機械可読タグの内部にテキスト・コンテンツを組み込むことによって、テキスト・コンテンツをプレゼンテーション (表示方法) から区別することでした。これによって、コンテンツとプレゼンテーションが別々の開発者によって作成されることが可能になっただけでなく、柔軟な再利用も可能になりました。
SGML文書の一形態であるHypertext Markup Language (HTML) もまた、意味を持つタグの内部にコンテンツを組み込みます。ただしHTMLには、コンテンツとプレゼンテーションを分離するという概念がもはやありません。HTMLを使ってWebページを比較的簡単に作成できるため、HTMLはほとんど世界中で採用され、同時にインターネット・インフラストラクチャーが広く普及しました。HTMLタグが標準化され、さまざまなWebブラウザーの間で理解される1つの言語が形成されました。しかしビジネス上の意図から、もっと洗練された動的サイトを構築しようとする試みがなされるにつれて、この言語の限界が次第に明らかになりました。
リスト1. HTMLフォームの例
... <!-- プレゼンテーション部分を省略 -->
<FORM action="http://www.example/ " method="post">
<P>
<INPUT type="radio" name="HairColor" value="Brown">Brown<BR>
</P>
</FORM>
|
リスト1 では、ユーザー・インターフェースを作成する同じコードの中でname="HairColor" およびvalue="Brown" が指定されていることに注意してください。さらにこのHTML断片では、ユーザー・インターフェースで表示されるウィジェット (ここではラジオ・ボタン) のタイプもまた、ハード・コーディングされています。このため、ラジオ・ボタンをサポートしないプラットフォームでは、このフォームが正しく表示されません。HTMLフォームにはデータがあらかじめ埋め込まれ、表示方法もハード・コーディングによって決定されているので、各フォームごとに表示内容を変えるのは簡単ではありません。HTMLの標準化によって、それぞれの開発者はHTMLタグ・セットを拡張できなくなり、この言語のカスタマイズの可能性、あるいは表示機能をより豊富にする可能性が制限されてしまいました。
Extensible Markup Language (XML)、およびXML文書タイプの1つであるExtensible Stylesheet Language (XSL) の導入によって、こうした問題を解決する試みがなされました。HTMLとは異なり、XML文書をXSL変換と組み合わせることで、データとプレゼンテーションの分離が可能になりました。たとえばname やvalue のようなフィールドをXMLデータとして保管する一方、XSL変換を使ってXML文書をHTMLに変えることにより、プレゼンテーションを作成できます。こうして開発者たちは、HTMLフォームの使用時に避けて通れないハード・コーディング上のさまざまな決定事項から解放されました。いろいろなXSLスタイル・シートを使用して、同じXMLデータをさまざまなスタイルで表示できます。逆に、1つのXSL変換を使用して、統一性のないさまざまなXMLを同じスタイルで表示することができます。加えて、XML/XSLはHTMLにはない拡張性を開発者に提供します。
XMLコンテンツをXSL変換して得られるHTMLには静的HTMLに比べて多くの利点があるものの、こうした機能拡張にはマイナス面もつきまといます。第1に、XMLからHTMLへの変換を行うサーバーは、静的HTMLだけを扱うサーバーに比べてパフォーマンスが劣ります。変換そのものにサーバー・サイクルが必要とされるだけでなく、フォーム生成時にクライアント / サーバー間の応答が何度も必要とされる場合があるためです。第2に、XSL変換を介したXMLの場合、HTMLだけをインプリメントする場合に比べてより高度な技術を要し、そのような技術をもつ開発者はそれほど多いわけではありません。
すでに述べたように、XForms仕様が開発された目的は、機能がより豊富でより動的なフォームをHTML文書に組み込むための拡張性を実現すると同時に、Webフォームの作成をより簡単かつ迅速にすることです。XFormsは、XHTML (XML互換性のあるHTML形式) の1つの拡張モジュールと考えることができます。XForms仕様には事前定義されたいくつかのタグ、要素、属性があり、これらを使えばWebフォームの作成が簡単になります。XFormsプロセッサーを実装したブラウザーは、XForms文書をクライアント上に表示することができます。これによって開発者は、Webフォーム更新時のサーバー / クライアント間の応答のためにパフォーマンスが劣化するのを避けられます。(さらに、開発者が希望する場合、サーバー・サイドのXFormsインタープリターを使用してXForms文書をHTMLに変換することもできます。)最も重要な点は、XFormsがフォームのデータ・モデル、ビュー、およびコントローラーを分離することです。これらの各部は、再利用可能な下位レベルにさらに細かく分解されます。たとえば、XFormsでは、フォームのビューがプレゼンテーション (presentation) と用途 (purpose) に分類されます。
XFormsのデータ・モデル部分では、データ値の表示のためのウィジェットとはいっさい無関係に、データ項目およびその構造を宣言することができます。XFormsは、これらのデータ項目を表示ウィジェットに関連付けるための手法を、データ・モードそのものの宣言とは別個に定義します。さらに、いずれかのデータ項目の値が変更された場合の処置を宣言する方法もまた、定義されています。
XFormsウィジェットは抽象的であるため、さまざまなプラットフォームが異なる方法でそれらを実装できます。たとえば、HTMLの<radioButton> タグの場合、さまざまなプラットフォームにおいてただ1つのプレゼンテーション を生成します (たとえばドロップダウン・メニュー)。一方、XFormsの<select1> ウィジェット (付録C4 を参照 ) の場合、パソコンのブラウザーではドロップダウン・メニューに、PDAではラジオ・ボタン・リストになります。しかし<select1> コントロールの用途 はどちらの場合も同じです。つまり、ユーザーが一連の項目の中から1つを選択できるようにすることです。
この記事では、XFormsの基本的なタグの重要な特徴について説明します。タグの使用法と構文、および基本的なタグに共通する属性の意味を示します。特定のタグについての説明では、仕様の詳細を見るために、この記事の付録へのリンクが提供されています。
まずは、おなじみの "Hello World" サンプルを使って、フォームの構造とXForms構文の初歩を見ていきましょう。さらにこのサンプルによって、XFormsと他のマークアップ言語を比較することができます。続くセクションでは、チュートリアルのために、e-commerce注文フォームの断片をサンプルとして取り上げます。
リスト2 は "Hello World" サンプルの全体を示し、図1 はこのサンプルがXForms互換ブラウザーでどのように表示されるかを例示しています。この文書の基本的な構造によく注意してください。すべてのXForms文書のレイアウトはこれと同様です。モデルがヘッダ (head) で定義され (XFormsモデルを参照)、ビューが文書本文 (body) で定義されていることにお気付きでしょう (XFormsユーザー・インターフェースを参照)。さらに、名前空間が各HTMLタグの中で定義されていることにも注意してください。命名の競合を避けるために、可能な限り、名前空間接頭辞を使用すべきです。
リスト2. Hello World
<!--Hello Worldサンプル-->
<html xmlns= "http://www.w3.org/1999/xhtml"
xmlns:xforms="http://www.w3.org/2002/01/xforms"
xmlns:my="http://www.example.com/my-data">
<head>
<!--モデルはxhtml文書のhead内で定義される-->
<xforms:model> <!--インスタンスはモデル内で定義される-->
<xforms:instance>
<my:data>Hello World</my:data>
</xforms:instance>
</xforms:model>
</head>
<body> <!--ビューは文書の本文 (body) で定義される-->
<xforms:group>
<xforms:output ref="/my:data">
<xforms:label>Output Control Example</xforms:label>
</xforms:output>
</xforms:group>
</body>
</html>
|
図1. 'Hello World' のレンダリング
なお、XForms言語用の実動レベルのプロセッサーがまだ存在しないため、レンダリング例はすべて手書き図であることに注意してください。これらはいずれも、特定のXFormsインプリメンテーションによって描画されたわけではありません。(ベータ版XFormsプロセッサーのリリースについては、参考文献を参照してください)
この記事の残りの部分では、e-commerce注文フォームの例について見ていきます。この注文フォームには、顧客情報を入力するセクション、価格情報を計算するセクション、ショッピング・カート内の品目をリストするセクションが含まれています。チュートリアルの第1部ではモデルの定義について、第2部ではビューの定義についてそれぞれ示します。サンプル・コードの全体は、付録A に示されています。図2 は、完成したサンプル注文フォームのレンダリングを示しています。
図2. 注文フォームの描画
XFormsモデルはフォームのコンテンツを示すので、プレゼンテーションが異なってもその内容は変化しません。モデルは、フォームのデータおよび論理コンポーネントから成っています。フォームのデータはインスタンス (instance) に含まれ (これについてはすぐ後で説明します)、すべてのフォーム・フィールド、および必要な一時記憶領域がフォーム・データに含まれます。フォームの動作を定義するのは、フォームの論理コンポーネントです。これらの論理コンポーネントを定義するには、イベント・ハンドラー (event handlers)、データ・バインディング (data bindings)、および処理依頼情報 (submission information) を使用します (これらについては、後のセクションで説明します)。
XFormsでは、同じフォームの中に複数のモデルを定義することができます。これは、1つのアプリケーションに複数の機能をサポートさせたいような場合に役立ちます。たとえば、ある個人用ポータルが、株価表示器モデル、カレンダー・モデルなどで構成されるとしましょう。複数のモデルが定義されていれば、id 属性を使って、それぞれを一意的に識別できます。リスト3 は、注文フォーム例のスケルトン・コードです。
リスト3. 注文フォーム例のスケルトン・コード
<HTML xmlns="http://www.w3.org/1999/xhtml"
xmlns:xforms=http://www.w3.org/2002/01/xforms
xmlns:ev="http://www.w3.org/2001/xml-events"
xmlns:xlink="http://www.w3.org/1999/xlink">
<head>
<title>XForms: Order Form</title>
<xforms:model>
... <!--インスタンスおよび論理コンポーネント-->
</xforms:model>
</head>
<body>
... <!--ユーザー・インターフェースをここに-->
</body>
</HTML>
|
すでに説明したように、モデルが文書のヘッド (head) で定義されていることに注意してください。次のステップは、インスタンス・データの宣言です。
XFormsモデルの仕様情報については、付録B6 を参照してください。
インスタンス・データ はモデル内部で定義されます。インスタンス・データは、バック・エンド、およびモデル内で必要とされる一時記憶領域に渡されるすべての情報を表します。ただし各インスタンスの中には、単一のXMLデータ・ツリーしか含めることができません。言いかえると、ルート・ノードはただ1つだけです。
インスタンスはモデル内でローカルに定義されるか、リモート・マシン上の既存のXMLデータをURIで示します。リスト4 は、OrderInfo という注文フォームの中でインスタンスをローカルに定義します。
リスト4. ローカル・インスタンスの定義
<xforms:model>
<xforms:instance>
<OrderInfo>
<PersonalInfo>
<Name>
<First></First> <Middle></Middle> <Last></Last>
</Name>
<Address>
<Street></Street> <City></City> <State></State>
<Zip></Zip>
</Address>
</PersonalInfo>
<PriceInfo>
<SubTotal></SubTotal>
<TaxTotal></TaxTotal>
<TaxRate></TaxRate>
<Total></Total>
</PriceInfo>
<TaxInfo>
<CT>.060</CT>
<NY>.085</NY>
<NJ>.083</NJ>
</TaxInfo>
<ShoppingCart>
<ProductInfo name="itm1">
<Quantity>5</Quantity>
<Description>Wht. Chocolate Bars</Description>
<UnitPrice>1.45</UnitPrice>
<ItemTotal></ItemTotal>
</ProductInfo>
<ProductInfo name="itm2">
<Quantity>8</Quantity>
<Description>Blk. Chocolate Bars</Description>
<UnitPrice>1.45</UnitPrice>
<ItemTotal></ItemTotal>
</ProductInfo>
<ProductInfo name="itm3">
<Quantity>2</Quantity>
<Description>Car. Filled Choc</Description>
<UnitPrice>1.80</UnitPrice>
<ItemTotal></ItemTotal>
</ProductInfo>
</ShoppingCart>
</OrderInfo>
</xforms:instance>
...
</xforms:model>
|
Inリスト4 のOrderInfo には、以下のような4つの主なコンポーネントがあります。
-
PersonalInfoには、ユーザーから得られるすべての情報が含まれます -
PriceInfoには、請求書の計算に必要な情報が含まれます -
TaxInfoには、合衆国州税 (日本の消費税にあたる) の税率に関する静的情報が含まれます。説明を簡略化するために、この例ではニューヨーク州、コネティカット州、ニュージャージー州のみの税率が定義されています。 -
ShoppingCartは、ユーザーが購買を予定している品目のリストです
従来、フォーム・データとは、単にユーザーからフォームに提供される情報のことだと考えられてきました。しかしPriceInfo およびTaxInfo セクションは、インスタンス・データをそれぞれ一時的変数および一時的定数として使用できることを示しています。
これに対してリスト5 では、リモートXMLリソースを参照することによってインスタンスを生成します。
リスト5. リモート・インスタンスの参照
<xforms:model>
<xforms:instance href="http://www.example.com/OrderFormData.xml"/>
...
</xforms:model>
|
インスタンス・データに関する仕様情報は、付録B5 をご覧ください。
XFormsでは2つの方法を使って値をインスタンス・データにバインドできます。つまり、あるデータを別のデータに依存させるか、あるいはユーザーの提供する入力にデータをバインドします。このセクションでは前者の方法について説明します。後者 (ユーザー入力バインディング) については、XFormsユーザー・インターフェースで説明します。
モデル内部で定義される<bind> タグによって、インスタンス・データを他のデータに依存させることができます。たとえば、リスト6 のステートメントは、計算された税額 (TaxRate にSubTotal を掛けた金額) にTaxTotal をバインドします。
リスト6. bindステートメント
<!--モデル内で-->
<xforms:bind ref="/OrderInfo/PriceInfo/TaxTotal"
calculate="/OrderInfo/PriceInfo/TaxRate *
/OrderInfo/PriceInfo/SubTotal"/>
|
ref 属性は、バインドしたいノード (ここではTaxTotal) を参照します。calculate 属性は、そのノードのバインド先の値を定義します。ここでは、TaxTotal をTaxRate とSubTotal の積にバインドします。calculate は、乗算の他にもいくつかの簡単な機能をサポートします (詳細は、付録D を参照してください)。
relevant 属性を使用して、bind タグが有効になる (つまり、タグが適用される) 条件を定義することができます。たとえば、TaxRate をリスト7 のようにバインドできます。
リスト7. relevant属性を含むbindステートメント
<!--モデル内で-->
<xforms:bind ref="/OrderInfo/PriceInfo/TaxRate"
calculate="/OrderInfo/TaxInfo/CT"
relevant="/OrderInfo/PersonalInfo/Address/State = 'CT'"/>
|
この<bind> ステートメントは、ユーザーがコネティカット州 (CT) に住んでいる場合にのみ (relevant 条件)、TaxRate (ref) をコネティカット州の税率に割り当てます (calculate)。すべてのケースでTaxRate を適切な州にバインドするには、同様のステートメントをニューヨーク州およびニュージャージー州に関しても定義する必要があります。
さらに、<bind> タグを使用して、インスタンス・データをさまざまな方法で制約することができます (たとえば、type 属性を使ってデータ型を設定します)。リスト8 は、SubTotal フィールドが常に小数値 (decimal) になるよう制約する方法を示しています。
リスト8. type定数を使ったbindステートメント
<!--モデル内で-->
<xforms:bind ref="/OrderInfo/PriceInfo/SubTotal" type="xsd:decimal"/>
|
インスタンス・データを制約する方法は、他にも多数あります (詳細については付録E を参照)。各フィールドごとに、XFormsプロセッサーは制約に照らし合わせてインスタンス・データをチェックします。いずれかのデータ制約に違反するデータをユーザーが入力した場合、XFormsをサポートするブラウザーはただちにフィードバックをユーザーに送ることができます。これによって、バック・エンド・プロセスは整形済みのデータだけを受け取るようになると同時に、ユーザビリティー・レベルが大きく改善されます。
バインディング、依存関係、および制約に関する仕様情報は、付録B2 を参照してください。
注文 (オーダー) フォーム・モデルを完成させるには、バック・エンド・サーバーとの通信を何らかの形で定義する必要があります。action 属性を<submission> タグで使用すれば、リスト9 のように、ユーザーが処理依頼 (サブミット) できる状態になったら呼び出しを起動するよう指定できます。
リスト9. submissionステートメント
<!--モデル内で-->
<xforms:submission id="submit1" action="http://www.example/" method="post"/>
|
さらに、HTTPメソッド (つまりget またはpost) を指定することもできます。なお、XMLコンテンツをカプセル化するために、常にpost を使用することが推奨されます。
同じモデルの中に複数の<submission> ブロックを含めることができます。その場合、id 属性を使って、それぞれの<submission> タグに固有の識別子を与える必要があります (たとえばid="sub")。ユーザー・インターフェースでは、これらのタグがサブミット・ボタンにバインドされるためです (submit を参照)。
<submission> に関する仕様情報は、付録B9 を参照してください。
ユーザー・インターフェースは、データ・モデル・インスタンスがページのプレゼンテーションに組み込まれる方法を定義します。これは、(たとえば<input> や<output> のような)原子的 コントロールによって、および (<group>、<repeat>、<switch> のような)複合的 コントロールによって表現されます。原子的コンポーネントは、フォームにデータを入れるために開発者が使用できる実際のウィジェットです。一方、複合的UIコンポーネントは、さまざまな原子的オブジェクトを編成およびグループ化するために使われます。すでに述べたように、原子的コントロールと複合的コントロールのどちらも、HTMLの場合のように、特定のプレゼンテーションにバインドされるわけではありません。これらのコントロールは特定の抽象的用途に関連付けられます。
<group>、<repeat>、および<switch> の各タグは、原子的なフォーム・コントロールを結合して複雑なユーザー・インターフェースを形成する機能を提供します。たとえば、大きなe-commerceフォームでは、複数の原子的オブジェクトをいくつかのセクションにグループ化することができます (たとえば、住所セクション、支払いセクション、品目セクション)。その後、これらのグループ を複合的コンポーネントとして扱うことができます。さらに、このような複合オブジェクトをネストさせて、他の複合的コントロールを作成することもできます。
group
group は最もシンプルな複合的コントロールで、複数のコントロールを1つのグループにする基本的コンテナーです。リスト10 は、大きなe-commerceフォームにおいてグループを1つのオブジェクトとして扱うために、さまざまなフォーム・コントロールをグループ化する方法を示しています。
リスト10. サンプル住所フォーム (AddressForm) の表示スケルトン
<body>
<xforms:group>
<!--AddressFormフォーム・コントロールをここに-->
</xforms:group>
</body>
|
groupに関する仕様情報は、付録B3 を参照してください。
repeat
<repeat> タグを使えば、フォーム内の冗長なコードを削減できます。開発者は、同じ型および構造をもつインスタンス・データ集合に対して、ユーザー・インターフェース・テンプレートを適用できます。注文フォームの例では、ショッピング・カート内の品目を図3 のように表示するために、<repeat> タグを以下のように使用します。
図3. repeatセクション
それぞれの品目 (item) に関するUIコントロールを明示的に書く代わりに、<repeat> タグを使用して、リスト4 のインスタンス内にあるShoppingCart セクションを繰り返します。
リスト11. repeatステートメントの例
<xforms:repeat id="shoppingcart" nodeset="OrderInfo/ShoppingCart/ProductInfo">
<xforms:output ref="Quantity"/> <xforms:output ref="Description"/>
<xforms:output ref="UnitPrice"/>
<xforms:output ref="ItemTotal"/>
</xforms:repeat>
|
リスト11 のrepeat 要素内のnodeset 属性は、モデル・インスタンスに関して評価されるXPathを定義します。続いてrepeat 要素はこのnodeset 全体にわたって、ネストされた各コントロールを繰り返します。
リスト11 では、ref 属性がProductInfo サブツリー内の各フィールドの値を参照します。さらに、XPathの前に@ を付けることによって、属性値を参照することもできます。たとえば、以下のような呼び出しを使って、それぞれのProductInfo のname 属性を参照できます。
ref = "@name" |
開発者は<repeat> タグを使用することにより、XForms文書をより短くして、実際のデータ・インスタンスをより反映させることができます。さらに、このタグはXForms言語の表現力を豊かにします。ショッピング・カートの中にいくつの品目が入っているかを知る必要 はありません。<repeat> タグがインスタンス・ツリーを自動的に全探索して、可能なすべてのマッチごとに出力を生成します。
<repeat> に関する仕様情報は、付録B8 を参照してください。
switch
<switch> ステートメントを使えば、動的なUI生成が可能になります。どのような条件のもとで別のUIを使うかを定義する<case> ステートメントが、各<switch> ステートメントに関して存在します。たとえばe-commerceフォームでは、ベンダーがユーザーの個人情報を得た後、支払い方法を確定したいと思うでしょう。<switch> タグを使えば、ユーザーが選択する支払いタイプに応じて分岐させることができます。ユーザーがクレジット・カードによる支払いを選択した場合、それに対応する一連のUIコントロールが生成されて表示されます。一方、ユーザーが現金その他の支払い方法を選択した場合には、フォームが別の表示コントロール・セットを生成します。<switch> タグによって、UIはユーザー主導型になります。
<switch> に関する仕様情報は、付録B11 を参照してください。
原子的コントロールとは、ユーザー・インターフェース設計のために開発者が使用できるプリミティブなコンポーネントです。これらのコントロールを使って、さきほど述べた3つの上位レベル・コントロールを実装できます。ここでは、いくつかの原子的コントロールについて見てみましょう。
input
最も基本的なフォーム・コントロールは<input> (入力) タグです。これは、すでにバインディング、依存関係、制約で述べたように、ユーザー提供データをインスタンスにバインドする方法の1つです。住所フォームの例を使った<input> タグの例が、リスト12 に示されています。
リスト12. inputステートメント
<!--ユーザー・インターフェース内で-->
<xforms:input class="ZipCode" id="zipcode"
ref="OrderInfo/PersonalInfo/Address/ZipCode">
</xforms:input>
|
このref 属性は、入力データのバインド先となるXPathを指定します。ref 属性はXPathを使ってインスタンスの場所を見つけますから、ノードが複数マッチした場合には (たとえば、複数の/AddressInfo/Address/Zip ノードが存在する場合)、ref は (選択すべきインデックスを開発者が明示的に指定しない限り) 最初のマッチを選択します 。この例では、ユーザーがこの入力フィールドに提供した値が/OrderInfo/PersonalInfo/Address/ZipCode にバインドされます。<input> タグの子<label> を作成することによって、入力フィールドのタイトルを追加する必要があります。(なお、<label> タグは、すべてのフォーム・コントロール内に作成できる多数のオプション・タグの1つにすぎません。そのようなタグの詳細リストは、付録F を参照してください。)
<input> に関する仕様情報は、付録B4 を参照してください。
output
<output> は単にインスタンス・データの値を表示するだけです。リスト13 の例では、計算された税額を<output> コントロールを使って出力します。
リスト13. outputステートメント
<!--ユーザー・インターフェース内で-->
<xforms:label class="label">Tax Amount $</xforms:label>
<xforms:output class="Amount" id="taxtotal"
ref="OrderInfo/PriceInfo/TaxTotal" />
|
このタグは、多くの点で<input> に似ています。唯一の違いは、<output> が読み取り専用であることです。
<output> に関する仕様情報は、付録B7 を参照してください。
action
<action> タグはXMLイベント・ハンドラーです。このタグは、最も標準的な使用事例を制御するいくつかの宣言XMLハンドラーとともに実装されるので、複雑なスクリプトを書く必要がなくなります。そのようなスクリプトのほとんどが長く複雑なうえに、必ずしもすべてのプラットフォームでサポートされるわけではありません。簡単に呼び出せるタグ・セットにXMLイベントをパッケージ化することによって、動的コンテンツの組み込みが簡単になるだけでなく、XFormsをサポートするすべてのプラットフォームで確実に動作します。
event 属性は、<action> タグがどのイベントをlistenするかを指定します。たとえばリスト14 では、注文フォーム内にrefreshForm アクションが定義されています。
リスト14. actionステートメント
<!--ユーザー・インターフェース内で、
またはUIフォーム・コントロール内に組み込んで-->
<xforms:action event="click" >
<xforms:refresh ev:event="xforms:activate"/>
</xforms:action>
|
click イベントが発生すると、actionイベント・ハンドラーはこのイベントを取得して<refresh> アクションを呼び出します。
同じ<action> タグの中に複数のアクションを含めることが可能です。イベント・ハンドラーがアクティブになると、その本文内部に定義されたすべてのアクションを起動します。(XForms宣言アクションの詳細リストは、付録G を参照してください。)<action> タグ内にこれらの汎用アクションを置くことによって、クライアント側ブラウザーは、ユーザー主導型イベントに応答してコンテンツを生成できるようになります。さらに、<action> タグはモデル内でも定義できます。次のセクションでは、<action> タグをフォーム・コントロール内に組み込む方法を示します。
<action> に関する仕様情報は、付録B1 を参照してください。
trigger
トリガーは、アクティブになったときにアクションを実行するUIコントロールです。たとえば、ユーザーのマウス・クリックに反応するボタンなどがその例です。トリガーがアクティブになるとXMLイベントを発行し、そのイベントは<action> タグで定義されたイベント・ハンドラーによって処理されます。XFormsでトリガーを定義するには、
リスト15 のようなステートメントを作成します。
リスト15. イベントを含まないtriggerステートメント
<!--ユーザー・インターフェース内で-->
<xforms:trigger>
<label>My Refresh Trigger</label>
</xforms:trigger>
|
このトリガーは何も行いません。このトリガーに何らかの処理を行わせるには、action で定義されているようなアクションをここに組み込む必要があります (リスト16 を参照)。
リスト16. 何らかの処理を行うtriggerステートメント
<!--ユーザー・インターフェース内で-->
<xforms:trigger>
<xforms:label>Reset</xforms:label>
<xforms:action event="click" >
<xforms:refresh ev:event="xforms:activate"/>
</xforms:action>
</xforms:trigger>
|
ユーザーがクリックしたとき、このトリガーはclick イベントをthrowします。このイベントは、
<action> イベント・タグ・ハンドラーによって処理されます。こうして<refresh> アクションが呼び出されます。
<trigger> に関する仕様情報は、付録B12 を参照してください。
submit
<submit> タグはトリガーを作成します。このトリガーは、ユーザーがクリックしたとき、<submission> タグ内部に定義されたアクションを呼び出します。(これは実際には、特定の<submission> タグに関連付けられたディスパッチ・イベントを含んでいるトリガーの別名です。)
リスト17. submitステートメント
<!--ユーザー・インターフェース内で-->
<xforms:submit submission="sub">
<xforms:label>Submit</xforms:label>
</xforms:submit>
|
<submit> に関する仕様情報は、付録B10 を参照してください。
XFormsを利用すれば、用途をプレゼンテーションからうまく分離した形で、Webフォームを定義することが可能になります。フォームのコンテンツや収集されるデータにもっと努力を傾けるようになり、表示スタイルにはそれほど注意を払う必要がなくなります。この言語が定義する強力なイベント・モデルのおかげで、フォームに関連した簡単なタスクを行うためにカスタム・スクリプトを作成する必要性がなくなります。
XFormsを使えば、開発者は制御すべきデータに注意を集中できます。データの構造と型は、標準的なXMLスキーマを使って明示的に定義できます。このモデルの拡張であるXFormsでは、追加の制約および依存関係を指定できます。XFormsプロセッサーは、追加のコードを必要とせずに、これらの制約を評価して実行します。処理のためにデータがサブミットされる前に、プロセッサーがデータ型および制約をチェックします。
さらにXForms仕様では、データ主導の条件制約を介して、動的フォームを作成できます。もはや、ユーザー応答に基づくカスタム・フォームを生成するために特別なコードを書く必要はありません。XFormsは、データが制御されて条件が変化している時点で、オンザフライでフォームを調整します。
XFormsを介したナビゲーションは、クライアント・レンダリングとは無関係に、XFormsイベント・モデルによって扱われます。同じXFormsをあるクライアントでは単一ページとして、別のクライアントでは複数ページとして表示することが可能です。状態の保存や、適切なナビゲーション・コントロールの提供といった事柄に頭を悩ます必要はありません。
簡潔な仕様ながら強力な機能を提供するXFormsを使って作成したフォームは、従来のWebフォームに比べて保守がはるかに簡単です。コードがプレゼンテーション・マークアップと混ざり合うことはありません。データ型を検査するコードを追加する必要もありません。データ構造は、プレゼンテーション・マークアップから完全に分かれています。
XFormsが用途とプレゼンテーションを分離する究極の ソリューションであるかどうかはともかく、次世代のWebフォームであることだけは確かです。
このペーパーの著作にご協力いただいた方々に感謝します。Lauretta Jones氏とSharon Greene氏は、何時間にもわたる編集上の援助と多大な励ましを与えてくれました。Angel Diaz、Paul Matchen、Matt Callery、Samuel Dooley、T.V. Raman、Rich Thompsonの各氏もまた、フィードバックとテクニカル上の助言を惜しまず与えてくれました。
- XFormsに関する W3C のサイトをご覧ください。
-
ベータ版リリースの XForms プロセッサーのリストをご覧ください。
- W3Cによる、XForms 仕様のワーキング・ドラフトをご覧ください。
- XForms の起源や目的といった経緯を理解するには、SGML 小史をご覧ください。
- XForms がどのように機能するかを理解するには、XML イベントを調べてください。
-
developerWorks XML ゾーンには XML についての情報が満載されています。HTML については、Web development ゾーン の豊富なトピックをご覧ください。
-
IBM WebSphere Studio Application Developer を入手してください。これは J2EE (TM) アプリケーションを構築、テスト、および配置するための使いやすい統合開発環境です。DTD やスキーマから XML ドキュメントを生成することもできます。
-
XML および関連テクノロジーに関する IBM 認定デベロッパーになる方法をご覧ください。
Joel Rivera氏はニューヨーク州ホーソンにあるIBM T.J. Watson Research Labで実習を受けている夏期インターンです。2001年にAngel Diaz氏の監督のもとでWebサービス用ブラウザーの開発に携わりました。その後、再び2002年にはLauretta Jones氏の監督のもとでNext Generation HCI Componentsチームに加わりました。2002年5月にUniversity of Puerto Rico, Mayaguez Campusで学士号を取得しました。関心のある分野は、分散システムと高性能車です。Contact Joel氏の連絡先はjoelr@ece.uprm.edu です。
Len Taing氏はニューヨーク州ホーソンにあるIBM T.J. Watson Research Labで実習を受けている夏期インターンです。IBM Researchに参加するのはこれで3度目の夏です。1999にはRoy Byrd氏のもとでニューヨーク州ホーソンのText Analysis Groupに加わりました。2000年にはCharles Wiecha氏のもとでマサチューセッツ州ケンブリッジのUniversal Interactionグループに加わり、2002年にはLauretta Jones氏のもとでニューヨーク州ホーソンのNext Generation HCI Componentsチームに加わりました。専攻はコンピューター・サイエンスで、ハーバード大学の最上級生になろうとしています。関心のある分野は、人工知能と中国映画です。Contact Len氏の連絡先はtaing@fas.harvard.edu です。