マイクとAjax の終焉
January 16th, 2008
Ajax 系のプログラムは以前から作っていたが、今回のものほど規模は大きくなく、エンジン部も全て自分で書いていた。特にXML でデータをやり取りとかはなく、直テキストでデータだけ送ったり、HTML を送ってinnerHTML でほりこんでみたり、あるいはJSON をeval してみたりという感じだった。
今回、「ボタンを押すと（ブラウザ内で）ポップアップウィンドゥが開き、その中で画面遷移する」、みたいなアプリをウィンドゥの中と外を極力切り離した形で開
発することとなり、方式をいろいろ検討した。ふと、横の人をみるとなにかしらjQuery とかThickBox とかいうのを使っている。JQuery でjavascript をJava や.Net みたいなイベントドリヴンに書けるみたいだし、ThickBox でポップアップする部分の中身をURL で指定すると
Ajax で取って来たり、まあ便利そうなので使ってみることにした。
次に中身をどうセットするかである。静的な表示と動的（表示するデータが変わる）な場合とを考慮して手法を検討しなければならないか？
１．Javascript の中に直接HTML を書いて、ポップアップウィンドゥのinnerHTML に。
var content = “<div>”;
content += “<h1>D’oh</h1>”;
content += “</div>”;
で、content をポップアップウィンドゥのinnerHTML に。
２．AJAX で中身を取得し、ポップアップウィンドゥのinnerHTML に。
今回は画面遷移が多く、システムを通してひとつのJavascript ファイルで根幹の部分を記述したい。１では、全部の画面データをそのファイルに含めると使いもしないデータが読み込まれまくっているのが微妙だ。
２の方式のようなAjax のリスポンス待ちはないが、今回は画面遷移の度にサーバーとデータのやり取りが生じることがほとんどであまり意味はない。
また、デザイン修正が大変そうなのに加え、ポップアップウィンドゥ内でのイベントをjQuery の強力なイベント処理機能を用いて記述しづらく、タグ内にonclick とか書くと処理を追えないようなコードになりそうだ。
さて、ThickBox では、a タグのhref にURL を指定すると表示するコンテンツをAJAX 的に取得して表示できる。AJAX 的にというのは指定されたURL の出力をそのままポップアップウィンドゥのinnerHTML にほりこむ感じである。ここで、デザインとビジネスロジック的なプログラムコードの分離を考慮した設計を前提にどのように動的データを埋め込むか考えると、
１．URL にPHP を指定し、PHP でSmarty などのテンプレートエンジンを用いて雛形となるHTML ファイルを読み込み、サーバーサイドでデータを埋め込んで出力。
２．URL に雛形となるHTML を指定し、JSON でデータを取得し、クライアントサイドで埋め込み。
素直に考えると１である。２では、HTML を読み込むのと、JSON でのデータ取得と、Ajax処理が２回発生し、クライアントサイドでデータを埋め込みというのが処理を遅く感じさせる。しかし、本件では２を選択してしまった。
まず、その時点ではJSONP を若干考慮していた。AJAX ではドメインが異なるURL からのデータ取得はできないが、script タグのソースはドメインの制限がないため、ドメインの異なるURL をscript タグのソースとして指定し、結果を変数にほりこむあれである。JQuery のJSON 関数はこれらを意識することなくデータが取得可能に設計されている。しかしながら、開発の時点でCertificate が取れていないHTTPS のURL からはデータが取得できないことが判明し、断念した。
次に、ポップアップウィンドゥの中のHTML にもjQuery によるイベント処理や画面遷移のためのThickBox の記述があるが、そういった処理がAjax やPHP を介して取得される部分にあるのが、感覚的になんとなく遠い気がした。
ということで、こういう形式にしてしまったわけだが、開発を通して様々な問題に気づいた。
- ブラウザごとに挙動が異なるJavascript。IE6,IE7, FireFox, Opera, Safari といった主要ブラウザで（時にはWin, Mac 版それぞれで）全動作確認をおこなうのは退屈で骨の折れる作業である。少しの修正でも、全体に影響をあたえることも考えられるし。
- 要求仕様が開発開始前に固まってればいいが、開発開始後にデータ項目が変わったりすると、DB, PHP, HTML, Javascript とそのデータを扱う箇所を全て修正する必要が生じ、精神的苦痛が大きい。
- Plug in などを用いての開発は、要求仕様がPlug in の機能内のうちはいいが、それを超えるような要求仕様変更が生じると、Plug inの中身を解析して修正を施すか、最悪Plug in 全体を自分で書き直すこととなり、想定外に時間を消費する。
- jQuery とPlug in とでVersion の互換性に問題がある場合がある。例えば、Interface Pluginの最新版は現時点でjQuery1.2 では全く動かない。
- jQuery ではHTML タグのID やクラス名で要素を取得して処理を、という形が多いが、デザイナーのCSS とぶつかると痛い。
- jQuery やPrototye.js といったフレームワークを用いると、それぞれでの開発経験がないとコードを追いづらいかもしれない。また、初心者がいきなりprototype.js を用いる前提でjavascript を書き出すと危険である。どこまでがjavascript の言語仕様で、なにがprototype.js の機能かわからなくなると微妙。
- 今年半ばに発表されるIE8 ではたして動くか？
まあとりあえず今回はjQuery でイベント処理部をHTML から分離し、画面毎のファイルも分割されているため、そんなにごちゃごちゃでもないと自分では思うが、PHP にも勝るとも劣らないJavascript の言語仕様のゆるさは、常人には理解しがたい混沌さを生み出すには十分である。特にグローバル変数のスコープは異なるドメインさえ駆け抜ける。
ということで、Ajax はもう無理です。そろそろSliverLight とかでいいです。
