Ajaxという技術手法が、大きく話題になっていることもあり、ここ1,2年の間で非常に多くのAjaxライブラリがWeb上で公開されている。 Ajaxを利用した機能を実装するには、可読性の悪いJavaScriptコードを書かなければならないため、少し凝ったことをやろうとするには多くの手間がかかっていたが、適切にAjaxライブラリを利用すれば複雑な機能も比較的楽に実装できるようになるだろう。
本節では、ライブラリを導入してAjaxの機能を実装していくための検討事項を紹介する。
Ajaxライブラリと一言で言っても、ライブラリごとに方向性が違う。便利な機能をどのような形で提供するのかを考えたときに、ライブラリを次のような二つのアプローチに分けることができる。 (※ コントロール型とエクステンダー型という形でライブラリを分類するアプローチもある）
ライブラリによっては(a). (b). の両方のアプローチを採用しているものもある。この二つのタイプが持つ特徴を理解した上で、どちらのアプローチを取るかは Ajaxの開発をする上で重要なので、各々の特長について考察する。
JavaScriptのAPIそのものがまとまって提供されているライブラリで、 JavaScriptのコード上でAPIを利用するという形で利用される。
このタイプのライブラリは、自分でJavaScriptの関数作った場合と同様、単にscriptタグを利用して宣言するだけで利用できるため、導入は比較的簡単である。また、JavaScriptにしか依存しないため、特定の言語に縛られることなく利用できるところにメリットがある。
代表的なライブラリとして次のライブラリが挙げられる。
ただし、単にJavaScriptの拡張ライブラリであるため、実装の複雑なJavaScriptを書いていかなければならない点で課題が残る。その課題を改善するためにあるのが次のタイプのライブラリだ。
JavaScriptは、多くの言語の中でも比較的柔軟性の高い言語で、かつブラウザに依存する仕様があるという理由から、どうしてもコードが複雑になってしまう。また、柔軟性が高い言語であるが故に、デバッグが難しいという側面も持っている。
このような理由からプログラマの中には、できるだけ直接利用したくない、できれば手慣れた言語でAjaxの機能を実装したいという開発者も多い。
そのような問題を解消するべく、JavaやRubyといったサーバサイドのプログラムのAPIという形で提供するアプローチをとるライブラリがある。 JavaやRubyで書かれたコードから、JavaScriptのコードを生成するという仕組みであるため、プログラマはJavaScriptを直接書かなくても、Ajaxの機能を実装することができる。
JavaScriptコードなしにAjaxが実装できることは大きなメリットであるが、 JavaScriptコードを隠蔽しているため、ライブラリの柔軟性に欠けるという側面もある。すこし細かいところで修正を加えたい場合、痒いところに手が届かないといった状況になりやすい。
一般的にこのタイプのアプローチは、ライブラリの範疇を超えて Webアプリケーションのフレームワークとして提供しているものに多く見られる。 Java ならば Google Web Toolkit、Ruby ならば Ruby on Railsの Ajaxライブラリ などがこのタイプに含まれる。（フレームワークに関しては後述する。）
二つのアプローチを比較すると次のような特徴を持っている。
この二つのアプローチのお互いの長所を知った上で、ケースバイケースで使い分けていくのが効果的である。
例えば、基本は実装を簡略化しスピーディーに開発を進めるため (b). のアプローチを採用し、行き詰まったら(a).のようなライブラリで補っていくという形が考えられる。このような形で開発を進める場合、Ajax対応のフレームワークを利用するのが効果的だ。そこで、Ajax対応のフレームワークについて次に説明する。
従来のWebアプリケーション開発で利用されるフレームワーク同様、開発言語ごとにAjaxに対応した開発フレームワークが、既に多く登場してきている。
前節で触れた通り、Ajax対応のフレームワークの多くはJavaScriptコードを意識しなくてもAjaxが実装できるというアプローチを取っている。 JavaScriptコードを隠蔽するアプローチは、細かいカスタマイズができないところにデメリットがあると紹介したが、 Ajax対応のフレームワークでは、手段は違えど、細かい部分にまでが届くような配慮がされている。
その辺りの対応方法もふまえつつ、いくつかのAjax対応フレームワークを簡単に紹介する。
ASP.NETの開発環境でAjaxを利用するためのフレームワーク。 ASP.NET Ajaxでは、サーバサイドでプログラムするアプローチだけでなく、 Microsoft AJAX Libraryと呼ばれる便利なJavaScriptのライブラリも多く提供しており、これらを利用してより柔軟に機能を実装することができる。つまり、(a).と(b).の両方のアプローチをフレームワークが持っており、必要に応じて使い分けることができる。
また、Visual Web Developerと呼ばれる高性能なAjaxの開発環境が用意されているのも特長の一つだ。
RubyベースのMVCフレームワークだが、Ajaxの機能も優れている。 Ruby On Railsの場合、「RJS」と呼ばれるJavaScriptコードをRubyのコードで簡単に隠蔽できる仕組みを持っている。標準でもよく使われるメソッドが用意されているが、開発者自身でJavaScriptコードを隠蔽したRubyのメソッドを自作することができる。
JavaScriptに強い開発者が一人いれば、その開発者にRJSのメソッドを作成してもらい、他の開発者がそれを利用するといった開発方法が考えられる。
実装を簡略化できるという以外にもフレームワークを利用することで得られるメリットは多い。まとめてみると、以下のようなメリットがあるように思う。
4. に関しては、Ajaxではバックグラウンドで何回も通信を行うため、セキュリティに対する意識が薄くなりやすいが、フレームワークがある程度カバーしてくれると心強い。
逆に上記の点を満たしているかどうかが、良いフレームワークかどうかを判断する一つの材料になると思う。
Ajaxを利用した開発を行っていると、クライアントサイドの機能が豊富になるため、どうしてもクライアントサイドのコードが複雑になり易く、保守性が悪くなりやすいように感じる。より大規模なエンタープライズシステムにAjaxを導入する場合、この問題は更に大きくなるだろう。
このような問題に対して、Ajaxを大規模なエンタープライズ開発にも適用できるようなアーキテクチャの改良が提唱されつつある。例えば下図のような従来のサーバ側のWebアプリケーションのみにMVCモデルを適用したものを、ブラウザ側に拡張しようという考え方である。
これをクライアント側にMVCモデルを拡張したのが下図である。
サーバ側にはView Templateが存在し、View自体はブラウザ側において、Event Handlerにより独自に状態遷移を行う。その際の制御のために、Controller機能の一部もブラウザ側に切り出してきたものとする。Ajaxの導入により、このような拡張がなされた、という考え方である。
Ajaxによる開発の場合、ブラウザからの操作を取得したり、画面の遷移を制御を行うJavaScriptコードがViewに入りがちだが、上記のアーキテクチャでは、画面の制御を行うJavaScriptの部分をControllerの一部と考え、画面(View)そのものと分離している。
かつてのMVCフレームワークが洗練されてきたように、Ajax対応のフレームワークに対してもアーキテクチャがより洗練されてきているようだ。
そもそも必要な機能がフレームワークに無い事もあるが、他の便利なJavaScriptのAPIを組み込んで補うこともできる。（単にJavaScriptの関数やオブジェクトなのでHTMLのテンプレートに組み込めば利用できる。）
Ruby on Rails の場合、標準でprototype.jsとscript.aculo.usが含まれているが、UIのサポートに関しては少々不十分な点もある。例えば、ボックスの角を丸めたり、ツリービューや吹きだしなどを表示するといった便利なUI部品は含まれていない。そのような場合、Yahoo! UI Libraryなど別のライブラリを導入することで解決できることがあるだろう。
それでは、他のライブラリを導入するために気をつけなければならないことを次に紹介する。
非常に多くのAjaxライブラリが公開されており、検索エンジンで検索してみると簡単に多くのAjaxライブラリを見つけることができる。ライブラリを目的別にまとめてリストアップしているサイトなども多くあり、ライブラリを探すのに役に立つ。
非常に多くのライブラリが公開されていることが分かる。これらの中からどのようにして欲しい機能を提供するライブラリを探せばよいのか手段をいくつか紹介する。
多くのAjaxライブラリ（特にUI系）では、大抵デモと、サンプルとなるソースコードが提供されている。
実際に動作するデモと、デモのソースコード（ソースコードが無い事もある）を見ることができる。これによって、どんなことができるのかを直感的に理解することができる。
デモを見ることは、そのライブラリの機能を見るには一番良い方法だが、すべての機能をデモで公開しているとは限らない。
ライブラリのリファレンスを見ることは、デモほど直感的ではないが網羅性がある。従って、ベースはデモを見ることで確認し、デモで拾いきれなかったところをリファレンスで補うという形が良い。
デモほど直感的ではなく、分かりづらい部分も多いが、どんなライブラリが提供されているのか一覧することができる。ただ、実際にどのような動きをするのかは見えないため、導入するときに検証して動作を確認することが必須となる。
このようにして必要な機能が提供されているライブラリが見つかったら、導入する前に最低限の調査や、簡単なサンプルを作ってみるなどしてテストすることが必要だ。どのような動きをするか、欲しい機能とマッチングするか詳しく見るためには、実際に動作を確かめてみないと分からないことが多いからだ。
次のような点は確認しておくべきだろう。
更に、将来性を考えるならば次のような点も確認したほうが良い。
JavaScriptは、ブラウザに非常に依存している言語で、あるブラウザでは軽快に動作していても、別のブラウザで動かないことがしばしばある。不特定多数のユーザがアクセスするようなサイトの場合は、特にクロスブラウザの対応は重要なポイントになる。
ライブラリがどのブラウザで動作するのか、提供元のサイトに書いてある場合があるので、システムがサポートするブラウザに対応しているかどうか確認しておくことが必要だ。（とはいえ、代表的なJavaScriptライブラリは、ほとんどクロスブラウザ対応はされている。）
よりシェアの高いブラウザに対応することが必須になってくるが、現在のところ、代表的なブラウザは「IE, FireFox, Safari, Opera」が一般的である。米NetApplications 社のレポート(http://marketshare.hitslink.com/report.aspx?qprid=0) によれば2007年3月これらのブラウザでシェアの98%以上を占めていることからわかる。
不特定多数のユーザがアクセスするサイトの場合、より多くのユーザに利用してもらえるように、多くのブラウザに対応する必要があるが、上記の４つのブラウザは対応されていることが望ましい。
特に、IEやFirefoxに関しては、シェアの多さから分かるとおり対応は必須になるが、 Safariに関しても、MacOSユーザの大多数が標準で利用するブラウザであるため、対応しているライブラリを導入するのが良いだろう。
導入するライブラリが、他のライブラリをベースとして作られていることがよくあるので、依存しているライブラリの種類とバージョンは確認しておいたほうが良い。
これは、複数のライブラリが同じライブラリをベースにしている場合があり、ベースとなるライブラリのバージョンが異なる場合にトラブルにつながりやすいためである。
JavaScriptには、Javaのパッケージのように名前空間を管理するための統一的な仕組みがないため、関数や変数名がコンフリクトする可能性がある。
上図は、実際にあったコンフリクトの一例を簡単に図にしたものである。 jQueryのthickbox.jsと呼ばれるライブラリで定義している「$()」関数を利用しようとしているが、 prototype.jsにも同名の「$()」関数が定義されているため、両方読み込んでいる場合にコンフリクトが発生する。
この問題が厄介なのは、数多くの関数が提供されているライブラリにおいて、導入する以前に名前が衝突するかどうか見つけるのは非常に困難なところだ。
これは、エラーの発生パターンがまちまちであるためである。通常コンフリクトが発生すると、他の同名のライブラリが呼ばれているため、大抵は、データがいつのまにかおかしくなっていたり、無限ループが発生したり、原因不明なエラーが発生する。
このようなコンフリクトを検知するには、優れたデバッガを導入するのが一番手っ取り早い。（優れたデバッガが導入されていることは良い開発環境を選ぶための一つのポイントである。）
もし利用する開発環境に実行をトレースできるような仕組みがないのであれば、次のような手軽に導入できる強力なデバッガもあるので利用すると良い。
Firebug は Firefox のアドオンとして提供されている、Webサイトのデバッグツールである。 JavaScriptのデバッグやトレース実行はもちろんのこと、送信したHTTPヘッダの解析、影響するHTMLやCSSの部分表示などが可能だ。 Firebug は非常に便利なツールなので、最後に詳しく紹介する。
コンフリクトの問題にあるように、現状ではAjaxライブラリを複数組み合わせて利用するための統一的な標準がないのが現状である。このような問題を解決するため2006年9月に「Open Ajax Alliance」と呼ばれるプロジェクトが発足した。
Open Ajax Alliance は複数のベンダが協力して、ライブラリ間の相互運用性を確保することを目標としており、業界での標準を策定したり、標準に準拠したフレームワークやツールキットを提供するといった活動を行っている。
導入するライブラリが、ベンダ製のライブラリであるならば、サポートについても考慮に入れておく必要があるだろう。ライブラリに不具合が合った場合、それに独自で対応するのはそれなりのスキルを要するためである。
オープンソースのライブラリでは、このようなサポートを受けられないことが前提のため、導入の敷居は高くなるだろう。
開発元のコミュニティなどが活発に活動しているかどうかも検討のポイントとなる。どのようなライブラリでも必ず不具合やセキュリティホールはつき物であるが、コミュニティが活発であればあるほど、不具合が発見された場合にすばやく対応してくれるケースが多い。
既にライブラリを活用してできたサイトがあれば、それ自体がデモとして参考になる。ライブラリを提供しているサイトに導入事例が記載されていることがあるので、チェックすると良い。
ここでは、ライブラリの調査と検討を一通り行った上で、プロジェクトへ導入する形になる。導入の最後のステップとして、アプリケーションを開発する上で気をつけるべき点や起こりうる問題について何点か紹介する。
ライブラリを導入する際にクロスブラウザの対応を検証することは前に説明したとおりだが、ライブラリがクロスブラウザに対応しているからといって、ライブラリを組み込んだアプリケーションがクロスブラウザで動作するとは限らない。テストの際には、必ず複数のブラウザでうまく機能するかどうかを確かめることが必須になる。
まずは、開発で利用するブラウザを一つ決めて開発/テストを行っていき、最終的に他のブラウザでチェックするのが効果的だ。ちなみに筆者の場合、先に紹介したFirebugを利用して開発を進めているが、まずFireFoxで一通りテストをしつつ最終的にIEや他のブラウザでもチェックを行うという方法で開発している。
アプリケーションを構築する際に、Ajaxを利用した通信を行うことで起こるセキュリティについてもある程度考慮を入れておかねばならない。従来のアプリケーションにおけるセキュリティ対策である程度は対応できるが、Ajax特有のセキュリティホールもあるようだ。
本稿では、詳しいセキュリティ対策については取り上げないが、留意すべきいくつかの点を記す。
Ajaxライブラリの導入に関する話題は以上だが、最後に本文内で触れたFirebugについて詳しく紹介する。
フレームワークに対応する開発環境では、サーバサイドに対する機能は割と充実しているが HTMLやCSSやJavaScriptといったクライアントサイドの開発に対してサーバサイド並みに充実している開発環境は少ないように思う。
Firebugは、クライアントサイドの実装を分析しデバッグする便利なツールである。 Firefoxのアドオンとして提供されているため、Firefox環境でしか利用できないが、Firebugを利用したいがために開発にFirefoxを利用している開発者も少なくないようだ。
Firefoxのアドオンであるため、導入も非常に簡単で、上記のURLにあるインストールボタンをクリックするだけでインストールができる。
Firebugの主な機能を次に紹介する。
inspect機能は、ページにカーソルを当てるだけで、該当するHTMLコードを見つけて表示してくれる機能である。作成した画面レイアウトが崩れていた場合など、実際に表示されたページのHTMLを見てデバッグすることがよくあると思うが、この機能を利用すると比較的簡単に問題の箇所を特定できる。
（操作: Firebug 上部のメニューで [Inspect]ボタンをクリックする）
更に、該当する箇所で有効なスタイルシートだけを表示してくれるのも非常に便利な機能である。
ブラウザでHTMLソースを表示するだけでは、通常Ajaxによって動的に更新された部分をHTMLで見ることができない。 Ajaxで更新された部分をメンテナンスしたいときによく不便に感じることなのだが、 Firebugでは、AjaxでHTMLの一部分に更新があった場合、更新箇所をHTMLでリアルタイムに表示してくれる。
該当するソースを表示するだけでなく、実際に編集することができるが、 Firebugが便利なのは、編集した時点でリアルタイムにWebページに反映されるところである。この機能は、レイアウトの微調整を行いたい場合に特に便利だと感じる。レイアウトを調整する場合、スタイルを編集してリロードして確認するという作業を延々と行っていくが、 Firebugならばリアルタイムに変更が確認できるため、手間が大幅に軽減される。
（操作: Firebugのソース表示画面で該当部分をクリックすると編集できる）
スタイルシートを編集する場合は上下キーを押すことで、数値を増減させたり、有効なスタイルの選択が出来るようになっているので、属性値を自分で調べる必要があまり無くなるところも便利である。
Firebugには、ページの読み込みにかかった時間をリクエスト別に解析して、図示する機能がある。 Firebugの優れている点は、通常のページ遷移だけでなく、Ajaxを利用した通信もモニタリングしてくれるところにある。
（操作: Firebug 上部のメニューで [Net]ボタンをクリックする）
実際にHTTPでどのようなデータが通信されたかどうかはデバッグする際に良く行うことだが実際に送受信されたリクエストとレスポンスの中身をモニタリングすることができる。 Ajaxアプリケーションを開発する際、どのタイミングでどのようなデータをサーバと通信しているかを意識することが多いが、この機能を利用すればすぐに確認することができるだろう。
（操作: 読み込みにかかった一覧の左部分の[+]をクリックすると展開される）
JavaScriptのデバッグを行う場合、Firebugを利用すれば、実行されるJavaScriptをトレースしたり、実行時のパラメータの値を確認することができる。操作が簡単でかつ細かい精度でトレースができるため非常に便利な機能である。
使い方としては、まずscriptの画面を開き、問題のありそうなコードの前後にブレイクポイントを設定する。
（操作: Firebug 上部のメニューで [Script]ボタンをクリック -> メニューでトレースしたい.jsファイルを選択 -> 行番号をクリックしてブレイクポイントを設定）
Webページ上で、JavaScriptを利用した動作を行うとブレイクポイントで処理が一旦停止する。このとき、ブレイクポイントの時点でJavaScriptオブジェクトに格納されているデータがすべて表示される。
ここから更にブレイクポイントから１行づつステップ実行ができる。これにより実行中のデータの遷移を見ることができるのが便利だ。
（操作: Firebugの上部メニューにある矢印のアイコンをクリックする）
Ajaxライブラリを探すところから導入するところまで、いくつかのポイントを紹介してきたが、実際に調査を行ってみると様々なライブラリが公開されていることに気づくと思う。
様々なライブラリに実際に触れてみることは重要だと思う。ライブラリのデモを見て触っていくことで、より優れた機能を発見することも大いにあるわけで、それらの技術を知ることは、より良いアプリケーションを開発するための大きな要素になっていくからだ。
本記事も、より良いアプリケーションを開発するための一つのヒントになれば幸いである。
本頁の著作権： Copyright (c) XML コンソーシアム 2007 All rights reserved. Copyright (c) メタデータ株式会社 2007 All rights reserved.