■ - hoshikuzu | star_dust の書斎

■AjaxAjaxAjax

Ajaxとは

アンテナで見てるとAjaxなる概念が浮上しているらしいということがわかりました。なんだろう？と疑問に思いました。あちこちと眉をくもらせながらわからんわからんと迷った末、下記の素晴らしい邦訳文献をみつけて大喜び。ありがとうございます。＞邦訳者殿

Ajax: Web アプリケーション開発の新しいアプローチ

ちょっと引用させて頂くと、

Ajax の定義

Ajax は技術そのものではない。それは、それぞれに繁栄している様々な技術を、新しいやり方で強力に組み合わせることなのだ。Ajax は次の技術の組み合わせである。

XHTML と CSS を用いた、Web 標準に基づくプレゼンテーション

Document Object Model によるダイナミックな表示と相互作用

XML と XSLT による、データの変換や操作

XMLHttpRequest による、データの非同期的な取得

それらを JavaScript によって結びつける

旧来の Web アプリケーションの動作モデルは以下の通りである。たいていにおいて、インタフェイスに対するユーザの操作により、Web サーバへのリクエストが発生する。Web サーバは、データを取得・解析し、旧式の様々なシステムとやりとりするといった処理を行い、それからクライアントに対して HTML ページを返す。それは、ハイパーテキストを媒介するという Web の元々の用途に適合するモデルではあるが、"The Elements of User Experience " のファンたちが知っているように、ハイパーテキストにとって都合がいいからといってそれが必ずしもソフトウェア・アプリケーションにとってもいいものであるというわけではない。

旧来のアプローチは多くの技術的な意義を生み出してきたが、しかし、優れたユーザ体験を生み出してきたわけではなかった。サーバが何か処理を行っている間、ユーザは何をしているのか？そう、ただ待っているだけだ。そして、タスクのあらゆる段階において、ユーザは何かを待っているだけなのだ。

はっきりしていることは、もし我々がアプリケーションデザインのために Web を一から作り直すとしたら、ユーザをただぶらぶらと待たせるようなことはしなかっただろうということだ。いったんインタフェイスがロードされたら、アプリケーションがサーバとのやりとりを必要とするたびに毎回、ユーザとのやりとりが止まってしまう必要があるだろうか。それどころか、アプリケーションがサーバとやりとりするのを、なぜユーザがいちいち見ていなければならないのか。

Ajaxと非同期性

どうやら非同期性が主役・鍵となるようですね。確かに以下のページでは非同期性を強く感じます。

ユーザが見ているページをクライアントページだとすると影にサーバ対向ページがあってサーバ対向ページがサーバ上のXMLデータベースとのやりとりをXMLHttpRequestで行っていると考えても良いのでしょうか？影でサーバへのリクエストを出しているからこそクライアントページでユーザは好き勝手なことをしているわけで。技術面をさっぱり知らないのでなんともわかりませんけれど。クライアントページのURLが不変なのにサーバ上のさまざまなURIを持つコンテンツを動的に表示していることが面白い。この辺が非同期性故の（結果として後からついてくる）特徴なのでしょう。

データベースはXMLデータベースでなくとも良いでしょうし、データベースへのリクエスト発行もXMLHttpRequestでなくとも構わないとは思いますが両者をあえて使うところもAjaxのAjaxらしいところなのでしょう。

ところで私は技術者ではありませんので、非同期性が果たしてXMLHttpRequestに起源を持つのかどうか全くわかりません。うーん。ただのリクエストに見えるのですよ。この偏見が間違っていなければ、クライアントページと（影の）サーバ対向ページとがあるお陰でJavaScript側で非同期部分を吸収しているのではないかと想像してみるわけです。JavaScriptはイベントを拾うのはお得意ですからね。ソースを見もしないで勝手に妄想の中でサーバ対向ページがあるはずだとぬかしておりますがご容赦下さい。先の素晴らしい邦訳ページの中の図中でAjaxEngineという存在がありますが私が今日の日記で妄想たくましく言っているサーバ対向ページというのはコレではないか、そんな気持ちなのです。

Ajaxに対するもっと激しい妄想

URLが変わらないで各種のデータベースサービスを受ける等サーバとのやりとりができるという、（Ajaxの本質とは異なるだろう）後付けの特徴なのですけれど、私はこれをもっと昔から似たような感触を得たことがあります。

まずクラッカー達がステルスで我々の手元のクライントマシンを受動的攻撃によって攻撃する時には私達ユーザの操作をイベントで拾って（あるいはオンロードだけで）悪さする場合。この場合ってどうなのでしょう。手元のURLを変えずに密かに悪意あるサーバとやりとりをするような仕組みって昔からあるのですよね。我々ユーザが見ているつもりのHTMLコンテンツの影で非同期に何かしらやってくれちゃうケースです。たくさん事例はありそうですが例えば、クリップボードの中身を定期的に悪意あるホストに送信し続けるデモは今でも見ようと思えば見れるはずです。最初に知った時には私はとてもビックリしました。自分の操作と非同期にサーバとのやりとりを行っちゃってくれるJavaScritなりActiveXなりって脅威だなぁと思ったものです。

昔から似たような感触があると言えば、もっと身近なものがあります。フレームを使ったサイトです。frameset要素などを使っているケース。左側にメニューフレームがあって右側にメインフレームがある。メニューから色々な指示をするとメインフレームのコンテンツが差し替わります。コンテンツを次から次へと見ていくわけですけれど、URLが変わらないことは皆さん良くご存知で。この件はAjaxの最大の売り物の非同期性とは無関係のように見えますけれどframesetそのものはJavaScriptを多用していないことが多いので非同期性が出てこない、とも思うのです。非同期性はJavaScriptが担っているはずだ、という私の偏見ですけれど。ここではみかけのURLが変化しないことの相似性を言ってみました。

激しい妄想はまだ続きます。

フレームにできることならインラインフレームでも似たようなことが出来るだろう、というのが私の妄想(笑)です。iframe要素を使えばURLが不変でも何か出来そうな気がしてきませんか？JavaScript併用でDOMをコントロールしつつですが、iframe要素で呼ばれるURLのページがサーバサイドスクリプトを含んでおり、サーバとやりとりして何かを持ち込んでくれる。たとえばデータベースを検索した結果を。そしてJavaScriptの変数経由で元の、私達が見ているページへ(URLは当然変不変ですが)返却してくれる。それをDOMのコントロールで閲覧可能な状態にしてさしあげる。

セキュリティ系のＭＬでみかけるPoCの一部がiframe要素を使っている理屈は、ひょっとしたらこれらの構造と似ているかもしれませんよね。無意識的でしょうけれど。

さて、URLが不変であることをもってして非同期性があるということは錯覚であるとしても、上手に作成すれば本当に非同期性を実現できるのではないでしょうか。

すみません。謝ります。どこからどこまでが私の妄想なのかは、みなさんに良く判断して頂きたいのです。ある程度の真実を私は妄想めかしてここで書き散らしているのかも知れません。

iframeでどこまで出来るか。

私の妄想でない部分をはっきりとさせておきましょう。私からの説明は手に余りますので、私が何を言わんとしているのかのご理解を皆さんにお願いいたします。参考文献を提示するだけですがお許し下さい。

まずはいくつかのデモ。そのうち少数はなんだこれ？という簡単なものです。ひょっとしたら最初は意図不明かもしれません。大団円まで辛抱して下さい。全部iframe要素とクライアントページ、サーバページが織り成す音楽です。簡単なものから複雑なものへとデモの例示をします。操作したりソースを見たりして遊んでください。

Remote Scripting with IFRAME

正直な所、Ajaxのお話しを本日知ったわけですけれど、Remote Scripting with IFRAME については先週に知ったのです。私にはこれらが良く似ていると思ったのです。似ている原因はなんだろう？と思いまして今日の日記を試しに書いて見ましたが、書く能力がなくて困りました。お読み頂いてありがとうございました。以下タネ明かし。元ネタです。

Remote Scripting with IFRAME: http://developer.apple.com/internet/webcontent/iframe.html

最後に：Ajaxを採用する技術者の皆さんにお願いしたいこと。

もう一度、冒頭の邦訳の解説をお読み頂きたいのです。そこにはこう書かれています。

ハイパーテキストにとって都合がいいからといってそれが必ずしもソフトウェア・アプリケーションにとってもいいものであるというわけではない。

Ajaxがブラウザ上でソフトウェア・アプリケーションをめざしていることはよくわかります。ハイパーテキストの本質はハイパーリンクであると思われます。そしてその本質を凌駕することがAjaxの目的なのでしょう。しかしながら私にはAjaxがハイパーリンクを捨ててしまったように見えます。URLが不変のままでコンテンツが動的に（データベースを参照しながら）ガシガシ変わる。本当にこれは福祉なのでしょうか。福音なのでしょうか。AmazonのデータベースをまさしくAjaxの手法で検索してみせるデモを本日拝見しました。すさまじい技術力です。残念なことにそのデモのURLを失念していますが、ご紹介できずに申し訳ありません。しかしながらURI、データ資源の存在の場所を示すポインタのないコンテンツは果たしてどれほどに有効なのでしょうか。調べた結果を示すURLを取得できないことって本当に福祉ないし福音なのでしょうか。ハイパーリンクを軽視したアプリケーションは万能なのでしょうか。非同期性は視覚的、みかけ上のものであり幻想ではないのでしょうか。なんらかの結果を得たければかならずサーバとのやりとりがあります。かならず待たされるはずなのです。それを視覚的に隠蔽することが本当に全ての場合に素晴らしいことなのでしょうか。私はGoogleのMapには確かに驚きました。ですがその調べた結果をどのように友人に伝えれば良いのでしょう。

また、JavaScriptが使えない、あるいは、あえて使わないユーザへの対応はどうなるのでしょう。

視覚的なこけおどしではなくて本当の意味で便利なものに応用できる場合にのみ、Ajaxを適用して頂きたいのです。たとえば、Google Sugestは良いものかも知れません。検索単語入力の補助に特化しているからです。あるいは何かのHELPをツールチップで出すことも有効かもしれません。但し、JavaScriptなしの環境でも当然ながら閲覧不可能であってはいけません。どうかAjaxの適用場所を間違えないで下さい。

新しい技術論は確かに面白いのですけれど、どうか、最初に技術アリ、ではなくて、最初にコンテンツありき、で考えて頂きたいのです。ハイパーリンク(ハイパーテキストの心臓部)を安易に殺さないで頂きたいのです。このことには大変な労力が必要なはずです。多くの場合、コンテンツを２重に作るはめになるからです。