dll 関数の補足と TODO
dll 関数 の補足と覚書
GM_xmlhttprequest の onload でなんで .call とかやっているかというと、一部ライブラリが this を window (Global) と仮定したコードになっているからです。eval のコンテキストの this を window (Global) オブジェクトにしてあげて、例えば MochiKit の export 先オブジェクトをそこにしてあげているわけです。
でもって、なぜ unsafeWindow でなく window なのかっていうのは、その export された関数とかが、ロードされたページに影響を及ぼさないためです。Greasemonkey 中の window はページ内のスクリプトからはアクセスできない (safe) ので、Greasemonkey 内限定で使う場合、副作用の懸念を減らすことができます。
でもって、id:brazil さんの記事 で、あああって思った。全部とってきてから eval したら、変に何回もリクエスト送らないでいいや。と、いう、か、GM_setValue 使えばいいんだけど、ちょっと GM_setValue で長い文字列突っ込むのは怖い。
関連エントリー
- GreaseMonkey で MochiKit 使ってみる。すなわち外部ライブラリの読み込み。あるいははてなのグラフが綺麗じゃない GreaseMonkey で外部ライブラリが使いたいな。みたいな。似たようなのでは CMS researcher - Greasemonke...
- Ruby's eash on ECMAScript ECMAScript でイテレータ なんてのを書いたことがあったけど、これ、each の中で break ができないのでちょっと気持ち悪い。...
- Javascript で require もどき・eval の実行コンテキスト Javascript はファイル間の依存関係を一切書けない。ロードする順番は結局 script 要素の出現順、つまり HTML 依存。どう考...
- ECMAScript での var 前に書いた気がするけど、ECMAScript の var は Io の setSlot に似ている。 var foo; と書くと、既存のスコ...
- ES2015 の iterable/iterator/generator による無限 FizzBuzz (オブジェクト指向編) ES2015 の iterable/iterator/generator による無限 FizzBuzz | tech - 氾濫原 に続いて、...