XQuery をプレゼンテーション層に使用する

特定の言語に縛られることなく関心事を切り分けるには

Comments

プレゼンテーションに XQuery を使用するメリット

MVC パターンのメリットは、Web 開発コミュニティーでは今やほとんど常識となっています。MVC とは、モデル (情報コンテンツ)、ビュー (ユーザーに対して画面に表示される内容)、コントローラー (ユーザーの入力や、ブラウザーでの URL 指定に対する動作) のそれぞれを切り離すパターンです。

開発者が MVC パターンの何らかのバリエーションを実装しようとするときには大抵、Java EE (Java™ Platform, Enterprise Edition 5) 技術を選択するのが常となっています。Java プログラミング言語は最先端の技術なので、確かにこれは確実なソリューションです。さらに分散オブジェクト・アプリケーションでは、Spring や Struts といったよく使われているフレームワークが MVC パターンを促進します。

しかし、ソフトウェアの開発においては、ベスト・プラクティスは常に進化し続けているという不変の法則があります。そうでなかったとしたら、Twitter は Pascal で作成されていたことでしょう。標準が進化するにつれ、ベスト・プラクティスはそれ自体が改革されていくか、場合によっては新しい方法やソリューションに完全に置き換えられます。要するに、今は Java Enterprise 技術の実装が一般的だとしても、それは同じく、過去のニュースでもあるということです。これと同じことは、Java プログラミング言語とは異なる他の MVC 実装にももちろん当てはまります。

それでは、現時点で答えとなるものは何でしょうか。関心事を切り分けるのに効果的な方法は、XQuery をビューに使用し、XML をデータとして使用することです。その理由を、これから説明します。

XQuery は XML と結束しています

ソフトウェア開発のベスト・プラクティスは常に進化し続けているとは言え、そこには息の長い技術がいくつかあります。そのうちの 1 つが、XML です。XML は情報を階層型構造で表しますが、この構造で使用する要素と属性は、一般的に読みやすい言語で作成されています。つまり XML は人間にとっても、コンピューターにとっても情報を読み取ることのできる最善の技術を意味します。

現在 XML は、ソフトウェア開発コミュニティーではほぼ普遍的に認められた情報交換手段となっています。特に Web サービスでのようにプラットフォームと言語への非依存性が要件となる場合には、XML が欠かせません。XML は Web フィードにも使用されています。RSS と Atom は両方とも XML に依存するためです。REST (Representational State Transfer) 呼び出しによる結果は、ほとんどの場合、XML フォーマットで返されます。さらに、ソフトウェアの構成を目的に使用されることさえ珍しくありません。

XML の普遍性を考えると、これを MVC パターンのモデルとして使用するのは当然のことです。そして、XML に対してクエリーを実行するための標準としては XQuery が一般的に使用されていることから、ビューを構築する際には XQuery 技術を使用するのが理にかなっています。ビューに使用する場合、XQuery は適切な表示にするための変換も可能にするという点がさらなるメリットになります。開発者は XML 文書から必要な情報を抽出できるだけでなく、その情報をアプリケーションの要件に適した方法で表示できるからです。

XQuery を使用すると「ごまかし」が効きません

開発者は時に、てっとり早い問題の修正手段としてハッキングを使いたくなります。これは必ずしも、開発者の落ち度ではありません。ソフトウェア・デリバリーの期限のせいで、物ごとに適切に対処するよりも、素早く対処するために近道を取らざるを得ないことがあるからです。しかし、これは政策上の議論であって、この記事には関係ありません。

MVC 開発者がビジネス・ロジックのコードを本来のサービス層ではなく、プレゼンテーション層に組み込んで「ごまかす」ことはよくあります。最もよくある例は、JSP コードでスクリプトレットを使用することです。大抵の JSP 開発者は、この誘惑に駆られた経験が (そして正直に言って、誘惑に負けてしまったことが) 1 度や 2 度はあるはずです。

ビューに XQuery を使用するメリットは、開発者が、このようなごまかしを使えなくなるところにあります。XQuery でビジネス・ロジックを作成することはできません。XQuery の焦点は、クエリーと変換にしか置かれていないためです。純粋主義者たちは、クエリーは別の層でも実行すべきだと主張するかもしれませんが、XQuery の場合、変数を外部にバインドすることによって、別の層で定義された変数をベースにクエリーを順応させることができるという点を忘れないでください。

XQuery はアプリケーションを特定の言語に縛り付けません

言語への非依存性が必要な場合、ソフトウェア・アプリケーション間でデータを交換する手段には XML が推奨されます。PHP アプリケーションは、Java アプリケーションが読み取り可能な XML 文書を、その方法はまったく異なるものの、そのまま読み取ることができます。

逆に、Java Enterprise アプリケーションでモデルとしてよく使用される Java Bean は、PHP アプリケーションでは簡単に読み取ることができません。同様に、Java アプリケーションでは、属性名を値にマッピングする PHP 配列を読み取ることはできません。この 2 つの場合、モデルがプログラミング言語に直接結び付いていることが、データ交換を阻止しています。

XML は、このようには制約されていません。ほとんどすべての言語 (すべての言語ではないとしても) では、データを表現する上で XML 文書を読み取り、構文解析し、作成することが重要であると認識しています。XML 文書はアプリケーション間で共有できるためです。それぞれのアプリケーションがそのプロセスでどの言語を使用しているかは全く問題になりません。

前のセクションでも言ったように、ソフトウェアのベスト・プラクティスは常に進化し続けています。しかし、XML は現存する言語のどれよりも長く使われ続けると思われます。そしてこのことは、アプリケーションが (特定の言語に限定されるモデルとは対照的に) XML をモデルに使用していれば、翌年に推奨される技術を使って更新するとしても、その影響を最小限に抑えられることを意味します。例えば、Java Bean をモデルとして使用している場合、次の年にそのアプリケーションを .NET に更新しなければならなくなったとします。この場合、その環境で使用される言語に従ってモデルも更新しなければなりません。一方、モデルが XML であれば、更新は必要ありません。.NET では XML 文書の読み取りが可能だからです。

XQuery をベースとした MVC アプリケーションの構築

ある朝、あなたがいつものようにコーヒーを飲みながら E メールをチェックしていると、上司がオフィスにひょっこり入ってきました。あなたに仕事を指示するためです。それは、fishinhole.com という会社の Web サイトを、言語に依存しない形で納品するという仕事です。上司は明らかにほくそ笑んで、この Web サイトは言語に依存しないようにする一方、MVC パターンはそのまま維持するようにと指示をすると、幸いオフィスから出ていきました。

あなたは上司の言葉のほとんどを覚えていません。彼のポケットに付いたケチャップの染みに気が取られていたからです。けれども作業の要点は明らかで、よく使われている設計パターン (MVC) を用いて、モデルとビューが特定のプログラミング言語に縛られないように、企業の Web サイトのコードを作成し直す必要があります。そこで、まずは落ち着いて実装から考えることにしました。

実装

あなたは、完全に言語に依存しないソフトウェア・アプリケーションなどというものは (まだ) 存在しないことを理解しています。ソフトウェアのすべての構成部分は、何らかの言語で作成しなければならないためです。そうは言っても、適切な技術を使うことで、fishinhole.com を言語非依存の方向に持っていくことは可能です。

その点を考慮して、コントローラーは Java プログラミング言語のまま維持することにしました。これは、URL リクエストを適切なリソースに実際に転送するコードだからです。また、Java プログラミング言語で作成された Spring フレームワークも現状のまま維持します。Spring は単純な MVC 機能の枠を超えて、中間層アクセス、トランザクション管理、アスペクト指向プログラミング (AOP)、依存性注入などの多くの機能をもたらします。

言語非依存性を実現するために、XML をモデルとして採用することにしました。XML を選んだ理由は、偶然にも、IBM developerWorks Web サイトに掲載されている XQuery をプレゼンテーション層として使用する方法に関する記事で説明している理由と同じです。

ビューには XQuery を選択するのが自然の成り行きのように思えます。前にも言ったように、XQuery は XML 文書に対してクエリーを実行する機能だけでなく、XML 文書を適切に表示されるように変換する機能も提供します。XQuery を使えば、クエリーが正しい結果を返すだけでなく、これらの結果を HTML フォーマットに変換して任意のブラウザーで表示することができます。

次に必要なのは XQuery 実装ですが、これにぴったりなのが DataDirect の XQJ (XQuery API for Java) ライブラリーです。このライブラリーが最適な選択となる理由は、コントローラーと同じく、XQJ も Java プログラミング言語で作成されているからです。XQuery ライブラリーは、Java プログラミング言語で作成された XQuery 実装のなかで、最もよく使用されていて確実な実装の 1 つとして数えられています。

プラットフォームについてはどうでしょう。この Web サイト (fishinhole.com) は、Apache Tomcat アプリケーション・サーバーにすでにデプロイされています。これまでコードの再作成について検討した事項はすべて Apache Tomcat に準拠するため、あなたは次に繰り返すアプリケーションも、同じ Apache Tomcat サーバーにデプロイできるはずだと判断しました。

ビジネス要件

ありがたいことに、上司はビジネス要件については変更しませんでした。彼が指示した内容は、ベースとなる実装に対する変更だけです。したがって、現在とまったく同じ要件一式を、今度は MVC と XQuery を使用して実現すればよいだけの話となります。

この Web サイトに対する既存の要件は、ユーザーが用途と形状を基準にルアーのカタログをブラウズできるようにするという単純なものです。用途には 2 つの選択肢 (キャスティング用またはトローリング用) が用意されており、形状にも 2 つの選択肢 (スプーン・タイプまたはミノー・タイプ) があります。サイトの構成としては、ユーザーが用途のオプションと形状のオプションを選択して Search ボタンをクリックすると、画面に選択基準と一致するルアーの一覧が表示されるというものです。

このアプリケーションでは、その際立った要件に気を留めておく必要もあります。その要件とは、ユーザーの入力に対する応答としてページ全体を更新できる回数が制限されていることです。この要件は現在、Ajax 実装で対処されています。これは、マーケティング部門からの譲れない要件であることがわかったあなたは、Ajax 実装を引き続き使用することにしました。

モデル

前述のとおり、モデルは XML フォーマットで保持されます。このモデルは、ルアーの価格、形状、在庫、出荷地域などの情報をルアーごとに保持しなければなりません。したがって、リスト 1 に記載する文書フラグメントのようなモデルになります。

リスト 1. XML フォーマットのモデル
<lures>
 <casting>
  <minnows brand="Yohuri" style="deep" size="3">
   <minnow color="midnight blue">
    <international-prices>
     <price denomination="dollar">3.25</price>
     <price denomination="euro">4.25</price>
     <price denomination="canadian-dollar">4</price>
     <price denomination="peso">100</price>
    </international-prices>
    <availability>
     <shipping>
      <delay>0</delay>
     </shipping>
     <regions>
      <shipping-region>United States</shipping-region>
      <shipping-region>European Union</shipping-region>
      <shipping-region>Canada</shipping-region>
      <shipping-region>Mexico</shipping-region>
     </regions>
    </availability>
   </minnow>
...
</lures>

XML 文書自体の内容は、見れば明らかです。各要素と属性には直観的な名前が付けられているため、XML 仕様を使い慣れていれば、じっくり読まなくても見るだけで情報を解析することができます。

コントローラー

このコントローラーの背後にある概念は、XQJ を使用して前述の XML 文書にクエリーを実行し、その結果を適切な表示に変換できるコードを提供することです。そこであなたは、この目的を満たすには XQJ を依存関係として使用する単純なサーブレットで十分だと判断しました。こうすれば Java コードを最小限に抑え、言語に依存しないモデルとビューという最終目標を達成することができます。

前述の Ajax 関数は、ユーザーが Search ボタンをクリックすると呼び出されます。この関数は単純なサーブレットに依存して、(XML に変換される) HTML フラグメントを取得し、DIV タグのコンテンツをこの HTML フラグメントに動的に置き換えます。ここで重要な点は、この Ajax が GET ではなく POST を使用してリクエストを処理することです。

Ajax 実装が POST メソッドを使うことから、この単純なサーブレットは doGet ではなく、doPost メソッドを実装する必要があります。リスト 2 に、この実装を記載します。

リスト 2. doPost メソッド
public void doPost(HttpServletRequest request, HttpServletResponse response) 
	throws ServletException, IOException {
 try {
	PrintWriter out = response.getWriter();
		
	String usage = request.getParameter("usage");
	String configuration = request.getParameter("configuration");
				
	if (usage != null && !usage.equals("") && !usage.equals("0")) {
		if (configuration != null && 
		 !configuration.equals("") && !configuration.equals("0")) {
			String xqFile = "c:/fishinhole/searchResults.xq";
			String lures = fetchLuresByUsageAndConfiguration
			 (usage, configuration, xqFile);
			System.out.println(lures);
			out.write(lures);
		}
	}
 } catch (Exception e) {
	e.printStackTrace();
 }

簡単に言えば、このメソッドは POST された 2 つのパラメーター (configuration と usage) を読み取り、これらのパラメーターの値を基に XML 文書に対してクエリーを実行し、適切な表示に変換後の XML 文書をレスポンスとして返します。このレスポンスの内容は、前にも言ったように、元のページで DIV タグのコンテンツに置き換えられます。

まず、このメソッドは HttpServletResponse オブジェクトのライターを取得します。このオブジェクトは、出力が書き込まれる場所です。

次にこのコードが取得するのは、2 つのパラメーター、usageconfiguration です。この 2 つのパラメーターは、Ajax がメイン・カタログ・ページで呼び出す POST の中に設定されます。

続く数行は、エラーを防止するための行です。基本的にこれらの行は、ユーザーが用途と形状の両方に有効な選択肢を選択せずに Search ボタンをクリックしたときに、ヌルまたは空の値をトラップします。

次に、XQuery ファイルの場所が指定されます。このファイルの中身についての詳細は後に回すことにして、現時点では、モデルである XML 文書を構文解析して適切な表示に変換する実際の XQuery コードはこのファイルに含まれているということを理解しておいてください。

リスト 3 に記載する fetchLuresByUsageAndConfiguration メソッドは、XQJ に依存してコードのクエリーと変換の部分を実行するローカル・メソッドです。

リスト 3. fetchLuresByUsageAndConfiguration メソッド
private String fetchLuresByUsageAndConfiguration(String usage, 
	String configuration, String xqFile) throws Exception {
		
	// Data source for querying
	DDXQDataSource dataSource = new DDXQDataSource();

	// Connection for querying
	XQConnection conn = dataSource.getConnection();
		
	XQExpression expression = getGenericExpression(conn); 
		
	expression.bindString(new QName("configuration"), configuration, 
		conn.createAtomicType(XQItemType.XQBASETYPE_STRING));

	expression.bindString(new QName("usage"), usage, 
		conn.createAtomicType(XQItemType.XQBASETYPE_STRING));

	FileReader fileReader = new FileReader(xqFile);
	XQSequence results = expression.executeQuery(fileReader);

	return results.getSequenceAsString(new Properties());
}

private XQExpression getGenericExpression(XQConnection conn) throws XQException {
	XQExpression expression = conn.createExpression();
		
	expression.bindString(new QName("docName"), "c:/fishinhole/fishinhole.xml",
		conn.createAtomicType(XQItemType.XQBASETYPE_STRING));

	return expression;
}

このメソッドの詳細については、この後すぐに説明しますが、とりあえず、このメソッドが String オブジェクトを返すことに注目してください。このオブジェクトは、適切な表示に変換後の XML を表す単なる HTML フラグメントです。そして最後に、前の行から返されたストリングがレスポンスに書き込まれます。

fetchLuresByUsageAndConfiguration メソッドは、3 つのパラメーターに依存します。最初のパラメーターはルアーの用途、2 番目のパラメーターはルアーの形状です。3 番目のパラメーターは、前述した XQuery ファイルの場所です。

最初にこのコードは (空のコンストラクターで) DDXQDataSource オブジェクトをインスタンス化します。DDXQDataSource クラスは、このメソッドのほとんどのクラスと同様、XQJ ライブラリーからのクラスです。

次に、初期化されたデータ・ソース・オブジェクトを使用して XQConnection オブジェクトを取得します。すると、このオブジェクトが getGenericExpression オブジェクトに渡されます。このようにして、パラメーター名 docName を、モデルを表す XML 文書とその場所とを示すストリングにバインドするというわけです。そして値がバインドされた XQExpression オブジェクトが、fetchLuresByUsageAndConfiguration メソッドに返されます。

続いてさらに 2 つのストリングが XQExpression オブジェクトにバインドされます。当然のことながら、これらのストリングは形状の値と用途の値です。

標準的な FileReader オブジェクトは、コンストラクターの中で XQuery ファイルの場所を示すストリングを使ってインスタンス化されます。この FileReader オブジェクトで、XQExpression オブジェクトは前にバインドされた値を使用してファイル内でクエリーを実行します。

クエリーの結果は String オブジェクトとして返されます。この String オブジェクトは、HTML フラグメントです。

ビュー

新たに改善された fishinhole.com のモデルは XML フォーマットですが、ビューは XQuery によって決定されます。XQuery は XML 文書に対するクエリーを可能にするだけではありません。XML 文書の変換も可能にします。この例での場合、XML から HTML に変換するので、任意の Web ブラウザーで容易に表示することができます。リスト 4 に、クエリーと変換を実行する XQuery を記載します。

リスト 4. XQuery ファイル (searchResults.xq)
declare variable $docName as xs:string external;
declare variable $configuration as xs:string external;
declare variable $usage as xs:string external;

<table width="100%" class="searchResultsTable">
	<tr>
		<th>Brand</th>
		<th>Color</th>
		<th>Configuration</th>
		<th>Size</th>
		<th>Usage</th>
	</tr>

{
if ($configuration = 'minnow' and $usage = 'casting') then
for $minnows in doc($docName)//casting/minnows
return
<div>
	{
	for $minnow in $minnows/minnow
	return
		<tr>
			<td>{data($minnows/@brand)}</td>
			<td>{data($minnow/@color)}</td>
			<td>{$configuration}</td>
			<td>{data($minnows/@size)}</td>
			<td>{$usage}</td>
		</tr>
	}
</div>
...

リスト 4 では、まず先頭の 3 行に注目してください。覚えているかもしれませんが、これらの変数はコントローラーのコード内で値にバインドした変数と同じです。

この 3 行に続くのは、変換の最初の部分です。この例では、変換は TABLE 要素とこの要素に対応するヘッダーで始まります。

次に、実際の XQuery コードが続きます。このコードがクエリーを実行し、ユーザーが指定した形状と用途に一致する結果だけが返されます。上記に示されている特定の例では、形状の値が minnow で、用途の値が casting である場合、この 2 つの値と突き合わせるクエリーが実行されて、一致結果が返されます。スペースを節約するため、リスト 4 にはすべての場合を記載していないことに注意してください。

ここでの特定のクエリーは、それぞれの casting 要素に含まれるすべての minnows 要素を見つけ出します。さらにそれぞれの minnows 要素内ですべての minnow 要素を見つけて、関連する値を抽出します。関連する値とは、ブランド (属性)、色 (属性)、形状 (バインドされた値)、サイズ (属性)、および用途 (もう 1 つのバインドされた値) です。

もう 1 つ、結果のそれぞれが HTML TD 要素、すなわちテーブルのセル内に返されることに注目してください。テーブルのセルはすべて、テーブルの行 (TR) のなかにラップされ、テーブルの行は DIV 要素でラップされます。変換のこの部分が、クエリーの結果を HTML テーブルに入力するというわけです。

カタログ・ページ

カタログ・ページはアプリケーションのエントリー・ポイントです。このページには、ユーザーが用途と形状の基準を選択するための選択肢があります。ユーザーが Search ボタンをクリックすると、このページに、選択された基準と一致する結果が読みやすいフォーマットで表示されることになります。

ページの大半は、HTML で作成されていますが、ユーザーが Search ボタンをクリックしたときにページ全体が更新されないようにするためには、Ajax も必要です。さらに、Ajax の j は JavaScript を表します。つまり、このページには JavaScript コードもあるということです。リスト 5 に、該当する JavaScript コードを記載します。

リスト 5. Ajax を呼び出す JavaScript コード
function search() {
	var usageElement = document.getElementById("usageSelect");
	var configurationElement = document.getElementById("configurationSelect");
	
	var usage = usageElement.options[usageElement.selectedIndex].value;
	var configuration = 
	 configurationElement.options[configurationElement.selectedIndex].value;
	
	if (usage == "0") {
		alert("Please select a usage!");
		return;
	}
	
	if (configuration == "0") {
		alert("Please select a configuration!");
		return;
	}
	
	var parameters = {};
	parameters["usage"] = usage;
	parameters["configuration"] = configuration;
	
	var resultsDiv = document.getElementById("searchResults");
	
	ajax("./updateResults",parameters,function(success,response) {
		resultsDiv.innerHTML = response;
	});
}

上記の JavaScript 関数は、ユーザーが Search ボタンをクリックすると実行されます。先頭の数行で、ユーザーが用途と形状を選択するそれぞれのドロップダウン・リストから値を取得します。これに続くのは、ユーザーが Search ボタンをクリックしたときに検索を実行する前に、実際に値が選択されていることを確実にするための検証ロジックです。

次に、空の配列が作成されます。この配列には、ユーザーがドロップダウン・リストから選択した値が入力されます。この例では、JavaScript 配列がハッシュ・マップのような役割を果たします。つまり、ユーザーが選択した値には、配列に含まれる数値のインデックス値ではなく、実際のストリング値が関連付けられるということです。この 2 つのストリング値は当然、それぞれ usageconfiguration と名付けられます。

これに続き、JavaScript 変数が、結果を表示する場所となる DIV 要素に関連付けられます。

この一連のコードの最後に Ajax コードが呼び出されます。呼び出しに使用される URL は ./updateResults で、この URL が、前に説明したサーブレット・コントローラー (リスト 2) にマッピングされます。サーブレットにはこのようにしてパラメーターの配列が渡されるため、ユーザーの選択した値を処理することができます。レスポンスが正常に行われた後、DIV 要素の innerHTML プロパティーに、サーブレット・コンテナーによって返された変換後の XML (つまり HTML) が入力されます。

すべてを 1 つにする

ここで重要なのは、構成です。この例の場合、モデルと XQuery ファイルはどちらも c:/fishinhole ディレクトリーに配置されています。この記事でこれまで記載したサンプル・コードとダウンロード可能なコードは、いずれもこのディレクトリーにある、この 2 つのファイルに依存しています。幸いこのディレクトリーは、特定のデプロイメントに対応できない場合には簡単に変更することができます。

知的所有権の理由から、付属の WAR ファイルに必要なライブラリーはアーカイブに含まれていません。該当するライブラリーは以下のとおりです。

  • commons-logging.jar
  • ddxq.jar
  • ddxqsaxon8.jar
  • ddxqsaxon8sa.jar
  • spring.jar
  • spring-web.jar
  • spring-webmvc.jar

上記のファイルを入手する方法については、「参考文献」を参照してください。

付属の WAR ファイルの WEB-INF/lib ディレクトリーに、上記の JAR ファイルを組み込めば、早速、デプロイメントに取り掛かれます。WAR ファイルのデプロイメント方法についての詳細な説明は、この記事ではしませんが、Tomcat に付属のマネージャー・アプリケーションを使用すれば WAR ファイルのデプロイメントは簡単な管理タスクとなります。

アプリケーションをデプロイした後、ブラウザーで以下の URL にアクセスしてください。

http://<server>:<port>/FishinHole/catalog.htm

ここで、<server> は使用している Web アプリケーション・サーバーの IP アドレス、<port> はその Web アプリケーション・サーバーのポート番号です。大抵のローカル・デプロイメントでは、http://localhost:8080/FishinHole/catalog.htm となるはずです。

このカタログ・ページは初め、まったくカタログ項目がない状態で表示されます。なぜなら、ルアーの基準がまだ選択されていないからです。ドロップダウン・リスト・ボックスを使用して、Usage リストのなかから Casting を選択し、Configuration リストのなかから Minnow を選択してください。選択し終わったら、Search ボタンをクリックします。最初は数秒かかるかもしれませんが、最終的には図 1 の画面が表示されるはずです。

図 1. 結果
結果
結果

結果を上司に見せると、彼は要件を満たすことができたことを少しも喜んでいないようでした。内心、自分に同じ仕事が任されていたとしたら四苦八苦することになったと知っている彼は、むっつりとしてオフィスを出ていきました。これであなたはまた椅子に深く腰掛けて、カフェラテの続きを楽しむことができます。

まとめ

XML をモデルとして使用し、XQuery をビューとして使用すると、言語に依存しないソリューションを実現できるとともに、MVC パターンを使用するメリットを損なうことのない確実な方法となります。特定のソフトウェア実装に依存しないソリューションは寿命が長く、長い目で見ればコスト効率を上げられるということは、ソフトウェア開発の歴史が証明しています。XQuery を使って XML モデルに対してクエリーを実行し、適切な表示に変換するという方法は、現代の Web アプリケーションで長期にわたって有効なソフトウェアを実現するための優れた方法です。


ダウンロード可能なリソース


関連トピック

  • XQuery入門」(Howard Katz 著、developerWorks、2001年6月、2006年1月更新): W3C が提案する XML 問い合わせ言語の標準について、背景となる歴史、ドキュメント化のロードマップ、そして仕様のその当時のスナップショットを含めて説明しています。また、XQuery の主な構文が持つ重要な機能についても概説しています。
  • Use XQuery from a Java environment」(Brett McLaughlin 著、developerWorks、2008年4月): Java アプリケーションで XQuery を使って文書を検索する方法を学んでください。
  • Ajax: 本著者は、ほとんどあらゆるサブジェクトについて学ぶときに最適な出発点としてウィキペディアを勧めています。Ajax も例外ではありません。
  • IBM XML 認証: XML や関連技術の IBM 認定技術者になる方法について調べてください。
  • XML Technical library: 広範な技術に関する記事とヒント、チュートリアル、標準、そして IBM レッドブックについては、developerWorks XML ゾーンを参照してください。
  • developerWorks podcasts: ソフトウェア開発者向けの興味深いインタービューとディスカッションを聞いてください。
  • Spring: この記事で紹介したコードをコンパイルして実行するために必要なダウンロードを入手してください。spring.jar、spring-web.jar、spring-webmvc.jar はこのサイトにあります。
  • Apache Tomcat: この記事のサンプル・コードをテストしたアプリケーション・サーバーをダウンロードして使ってみてください。
  • Java: Sun の標準エディションの Java プログラミング言語を入手してください。
  • An XQJ Tutorial: Introduction to the XQuery API for Java: このチュートリアルに、XQJ のダウンロード手順と使用方法が記載されています。説明に従って、ddxq.jar、ddxqsaxon8.jar、ddxqsaxon8sa.jar を取得してください。
  • Commons Logging: よく使われているいくつものロギング実装をサポートする commons-logging.jar を入手してください。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML, Java technology, Open source
ArticleID=380515
ArticleTitle=XQuery をプレゼンテーション層に使用する
publish-date=03102009