※公開用にいくつか手を加えてあります 前フリが長いとのツッコミがありましたので、今回の発表内容を少し要約してみたいと思います。 1. GIF Format Hacks (Server side) まずは、任意のpixelサイズ(幅・高さ)を持った画像ファイルを固定長の35byteで出力する方法 #!/usr/bin/perl use strict; use warnings; sub create_gif { my $size = pack "S2", @_; return "GIF89a$size\xf0\x00\x00\x00\x00\x00\xff\xff\xff," . "\x00\x00\x00\x00\x01\x00\x01\x00\x00\x02\x02L\x01\x00;"; } print "Content-Length: 35\n"; print "Content-Ty
http://d.hatena.ne.jp/shinichitomita/20061025/1161776282 の続き。 結局dojoのXhrIframeProxyで参考にすべきところは、fragmentIdentifierを使ってフレーム間でメッセージのやり取りをしているところ。つまり、同梱の xip_server.html とxip_client.htmlが偉いのであって、そこにおいて dojo.* のパッケージが何かしてくれているというわけではない。 そのフレーム間やりとりのプロトコル実装はdojoのを流用して、その値を取り出してオブジェクトとして受け渡すところのスタブとなるオブジェクトはdojoに頼らずこっちで書いてしまってもよい。そうすればクライアントは別にdojoでなくてもつかえるはず。 ということで、非dojoバージョンのXhrIframeRequestを作ってみた。サーバ
これおもしろいな。 http://dojotoolkit.org/~jburke/XHRIFrameProxy.html XMLHttpRequestがドメインの壁を越えられないのは悲しい事実。すべてのブラウザで改善されるのを待つのはひどく気の長い話だし、そもそもそうなってるのにはそれなりの理由(セキュリティ関連)があったわけで、うまく要求が通るとも思えない。 そこで、既存の枠組みでクロスドメインの壁を越えられる動的スクリプトロードでのJSONコールみたいなテクニックが出てきてるわけだけど、データソースとなるサーバ側でデータをJSON形式で用意しなきゃいけなかったり、結局JavaScriptロードに頼るので信頼できないサイトからは気軽にデータを取って来れない(⇒任意のJavaScriptコードが実行されてしまう危険性がある)などの問題があった。 IframeProxyはこれを回避する。IF
以前にここで触れた http://d.hatena.ne.jp/shinichitomita/20060803/1154609128 について、最近0.4.0でパッケージに正式に含まれたらしいので、ちょっと試してみる。 テスト内容 http://stomita.web.fc2.com/xip_test.html から、サイトの外にある http://www.geocities.jp/stormriders999/fruits.xml のデータを取得し、表示 セットアップ dojo 0.4.0をダウンロード http://download.dojotoolkit.org/release-0.4.0/dojo-0.4.0-ajax.zip 圧縮ファイルを展開し、dojo-0.4.0/src/io/xip_server.html を http://www.geocities.jp/stormri
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く