<%Dewplayer(javascript)%> 肉少なめ | Item - javascriptライブラリを重複しないように読み込ませる3つの方法

javascriptライブラリを重複しないように読み込ませる3つの方法

Title :
javascriptライブラリを重複しないように読み込ませる3つの方法
Posted on :
2007-02-17
Author :
NKJG
Category :
Nucleusメモ
Hatena Star :

本文

リンクベイティング風。こんなのに釣られる人はいません。

ねらい

Nucleus(特に管理画面)でprototype.jsとかscript.aculo.usとか読み込むプラグインが複数あると、どのプラグインで読み込んでどのプラグインで読み込まないか悩みます。私は。

なので、解決法的なもの妄想中。とりあえず以下3つ。

  • 専用のプラグインを用意する。
  • イベントを作って管理する
  • 定数を作って管理する

それぞれのネタ

専用のプラグインを作ってしまう方法

例えば、あるプラグインAがprototype.jsを使用する場合でも、そのプラグインで直接的にscript要素の出力などは行わず、ライブラリをロードするだけの専用プラグインBを用意して必ずそれを使うようにする。そのときgetPluginDep(だっけか)メソッドを使ってAはBに依存するように設定しておく。Aと同様のプラグインCが存在した場合でも、ロードをBに任せてしまうことでAとCで二回同じライブラリがロードされる現象を防ぐことができる。

このプラグインに名前をつけるならNP_SharedLibsでどうでしょう。

イベントを作って管理する

SpamOverrideイベントと同様の感じ。あるプラグインAがprototype.jsをロードするscript要素を出力した場合、そのイベントはPostLoadLibrary(仮称)イベントをfireする(引数のどこかで"prototype.jsのロードですよ"と明言する必要アリ)。Aと同じprototype.jsを使用するプラグインはPostLoadLibraryイベントを把握して同じscript要素の出力を自粛する。

またはライブラリをロードするための要素を出力する前にPreLoadLibrary(仮称)イベントをfireして、"出力済みだ"という結果が返ってきたら自粛、とか。無駄に実行されるイベントの数が増えてしまい待ってメリットがない感じか。

定数を作って管理する

_LIBRARY_LOADED_PROTOTYPE_DOT_JSみたいな定数で管理。イベント管理版の下と大体同じだけど何倍も早いはず。きっと。ただ定数の名づけ方に無理がありすぎ。

今のところ

イベント案(前)しかない気がしてきたまである。プラグイン案ではどうしてもトリッキーなプラグインを用意しなくてはならないはず。利点も特に無いし。