Apr 14, 2005
[Ajax] JSAN構想とリモートデータの取得とUserJavaScript
通常、JavaScriptを使って動的にデータを読み込む際には、データソースが同一ドメイン上にある必要があります。XMLHTTPRequestを使う場合でもIFRAMEを使う場合でも同様です。
ですが、scriptタグを使う場合に限り、ドメインの制約を受けずにデータを取得することが出来ます。
検索結果をページに貼り付けるJavaScriptなどでよく使われる方法ですが、これを応用して、外部ドメインに置いてあるライブラリやデータを動的に取得するというアプローチを考えています。
同じようなことを考える人はいるもので、CPANのJavaScript版、JSANという構想がuse Perlにポストされています。
http://blog.bulknews.net/mt/archives/001649.html
で、先月からずっとライブラリばかり作ってたのですが、
一応、問題なく動くレベルまでは来ているので、サンプルでも公開したいと思います。
http://la.ma.la/misc/js/jsan.html
http://la.ma.la/misc/js/suggest.html
スクリプトのインポート方法の比較などは、まだ書きかけですが、ここにまとめようかと思います。
http://ma.la/mirrorman/wiki.cgi/%e3%82%b9%e3%82%af%e3%83%aa%e3%83%97%e3%83%88%e3%81%ae%e3%82%a4%e3%83%b3%e3%83%9d%e3%83%bc%e3%83%88
----
一つ目は、外部ドメインに置いた「ライブラリ」を動的ロードするというものです。
初回実行時に、通信が発生しますが、サーバーサイドでの計算結果を取ってきているわけではありません。
JavaScriptのライブラリを受信して、計算はローカルで行います。
JavaScriptにはsleepが無いのでライブラリの読み込みが完了してから処理を再開する、といったことが出来ません。
なのでタイマーを使って、ライブラリが読み込まれるのを監視する関数を作ってやる、という方法を取りました。
同一ドメイン上からライブラリを受信する場合は、XMLHttpRequestの「同期モード」でjsファイルを受信してeval、という方法を使えば、
完全に通信が終了してから処理を実行することが出来るので簡単です。(ただし通信完了までブラウザが固まるという問題はあります)
実際に読み込まれるライブラリのファイルはこれです。MD5はコーディングスタイルの実験作なので、何かと余計な部分が多々あります。
http://ma.la/lib/Digest/MD5.js
http://ma.la/lib/MIME/Base64.js
元のアルゴリズム部分は高度なJavaScript技集から、拝借しました。
http://www.onicos.com/staff/iz/amuse/javascript/expert/
関数名やライブラリへのインターフェースをPerlに似せているのは、
サーバーサイドで同等の処理を行う場合の移植性を高めるため、というつもりなのですが
大して意味は無いかもしれません。単なる趣味です。
----
二つ目は、GoogleSuggestの検索結果を読み込むというものです。外部ドメインの「データ」を取得するサンプルです。
サーバーサイドでのプロキシ処理は行っていません。完全にJavaScriptだけで、Googleから直接検索結果を取得しています。
検索エンジンがJavaScriptで検索結果を出力するインターフェースを備えていれば、CGIが使えないサーバーでも、クライアント側の制御だけで動的に検索結果を読み込むことができるようになります。
JavaScriptでの検索結果出力といっても、現在良く使われているdocument.writeを使って画面に書き出す方式ではうまくいきません。
GoogleSuggestで動的に読み込まれるコードは、親ページにある「sendRPCDone」という関数に検索結果を渡しています。
特定の名前の関数に検索結果を渡してやる、という共通化されたインタフェースがあればいいのではないかな、と思います。
----
外部ドメインに置いたライブラリの動的ロードが出来ると、何がうれしいかというと
-CPANのようにライブラリを一極集中してメンテナンスをすることが出来るようになる
-アプリケーションが巨大化した場合、ライブラリを必要に応じて読み込むことで起動時間を短縮できる
というのがまず考えられますが、それ以上に大きなメリットは、
ライブラリのパスを自分の編集権限のあるローカルディスクなどに設定してやることで、
ウェブサイトの機能を、自分で自由にカスタマイズできるようになる、ということです。
スクリプトが上手く動作しない場合は、jsファイルを自分のHDDにコピーして編集し、動くように修正してやることが出来ます。
新しいバージョンが気に入らない場合は、自分だけ古いバージョンを使い続けることが出来ます。
あるいは、ウェブサイトを勝手にバージョンアップして、開発者にコミットしてやることが出来るようになります。
これは、編集ツールがフリーではないFlashに対する大きなアドバンテージになるのではないかと考えています。
他人のウェブサイトの機能を勝手に拡張するというのは、非常識なことなのかもしれませんが、Firefoxの拡張「Greasemonkey」がすでにそれを実現しています。
OperaもOpera8のbeta3からUserJavaScript機能を搭載しています。
http://japan.cnet.com/news/media/story/0,2000047715,20081548,00.htm
UserCSSが所詮、見た目のカスタマイズしか出来ないのに対して、
UserJavaScriptはウェブサイトの全ての機能をフルカスタマイズすることができます。
ウェブサービス、特に検索やソーシャルブックマークなどの多くの人が頻繁に使うものについては、正しいインターフェースというものがなく、
サービス運営者が使いやすいと考えるユーザーインターフェースが、他の人にとってもそうとは限りません。
文字だけで良い人もいれば、サムネイル画像さえあればいい、という人もいます。
機能や視覚化の手法などはユーザーが自由にカスタマイズできるように開放してやること、
今後はそのあたりが重要になっていくのではないかな、と
まあそんなことを考えています。
Edit this entry...
wikieditish message: Ready to edit this entry.
A quick preview will be rendered here when you click "Preview" button.