[XCL2.2] Javascript ライブラリ
氷川 霧霞
そろそろ XOOPS にも各種 javascript ライブラリが入りつつありますので、
可能であればXCL2.2で取り扱いのための仕組みを持てたらなあと考えて
います。
が、僕は jQuery をちょろっと使ったことがあるくらいで、prototype.js や
他のライブラリのことはまるで知りませんし、いろいろ面倒なことがありそうな
気はします（テーマ側の対応も必要とか）。
解決方針案も出していますが、あまり深く考えていません。
なので、すぐにできること、時間のかかること、無理なことなど、混在している
かと思いますが、放置しておくと各モジュールで好き勝手ライブラリを読み込
んで、状態はどんどん混沌へと進んでいくことになると思いますので、2.2 に
なるこの機会に、あるいは次期ベースでは同じことが発生しないよう、皆さん
の知恵を拝借しながら検討していけたらいいなあと思います。
現状と問題点
（1）モジュールごとにライブラリを重複保持
現在、各モジュール作者が javascript ライブラリ（prototype.js や jQuery）を
モジュールと一緒に配っている。しかしモジュールごとに配布するのは非効率
的だし、置き場所も決まっていないため、同じライブラリをあちこちに持つ状態
が発生しかねない。
また、同じ場所に置くにしても、バージョンの違いによって上書きしていいのか、
すべきなのか、サイト運営者は迷うことになってしまう。
（2）ライブラリの二重読み込み
javascript ライブラリをモジュール内で使っている分にはまだ問題にならないが、
ブロック内、あるいはテーマ内で javascript ライブラリを使うようになると、同じ
ライブラリを複数回読み込む可能性が出てくる。
たとえば、$xoops_module_header で jquery.js を読み込む指定をし、さらに
$xoops_block_header でも jquery.js を読み込む、ということが（特にモジュール
の作者とブロックのモジュールの作者が別の場合）起こりえて、エラーの原因
となりうる。
（3）サイト全体に適用する javascript
サイト全体に適用したいような javascript があった場合（たとえば tooltip や
ボックスの角丸化、Google Analytics）、現状だとテーマに直書きになるが、
これだとテーマを変更した場合に全て移さなければならない。テーマチェンジャ
を使っていたりすると特に面倒。
解決方針案
>（1）モジュールごとにライブラリを重複保持
置き場所と命名規則を決める。
>（2）ライブラリの二重読み込み
管理画面より、読み込むライブラリ（とバージョン）を指定できるようにする。
指定したライブラリは、テーマ内の xoops_script_library のような場所に書き
出される（あるいは、xoops_module_header の先頭に追加する）。
モジュール側で使いたいライブラリがある場合は、legacy に読み込み依頼を
する。依頼された legacy 側では、あちこちからの依頼によって二重読み込み
が発生しないようコントロールする。
>（3）サイト全体に適用する javascript
（2）と同様、管理画面より javascript の script を追加できるようにする。
追加した script は、xoops_script_header みたいな場所に書き出される
（あるいは、xoops_module_header に追加する）。
とりあえず以上です。
hiro1173
以前は各モジュール側でjavascriptのライブラリを持っていたのですが、だんだんとバージョンの管理が出来なくなってしまったので、
現在は、jsというディレクトリを基準にライブラリごとにパスで区切っていく形で管理をしています。
氷川さんの案でいうと＞置き場所と命名規則を決める。に該当します。
基本は、jsというディレクトリを基準にライブラリごとにパスで区切っており、単体の場合は、jquery-1.2.3.pack.js という風に
ファイル名を変更しています。
ライブラリのバージョンで区切る場合は、ライブラリ単位で /js/yui3/といった感じです。
jQuery・Ext JS・Yahoo! User Interface Libraryを設置する場合には、こんな感じ。
extjsやyui3は、実際には使ってないけどサンプルということで・・
/js/jQuery/
/js/extjs/
/js/yui/
/js/yui3/
また、jQueryなどプラグインで拡張する場合があるので、プラグインはライブラリの下に設置します。
/js/jQuery/cfJq_tab/ // タブのコントロール
/js/jQuery/flip/ // コンテンツの反転
jQueryを呼び出す時は、/js/jQuery/jquery-1.2.3.pack.js を呼び出します。
XOOPS_JS_URLとかを定数で持ってくれると、
XOOPS_JS_URL. "/jQuery/jquery-1.2.3.pack.js" といった感じで使えるかと思います。
また、私の場合は、javascriptを書くのが面倒なのでphpのライブラリから書き出す様にしてて、同様にlibというディレクトリで管理してい
ます。
Web API に関するファイルもこちらに置く様にしています。
/lib/webservice/googlemaps/GoogleAjaxAPI.class.php // Google Maps の
クラス
/lib/webservice/googlemaps/GoogleStaticMaps.class.php // Google
Static Maps のクラス
/lib/webservice/YahooMaps.class.php // Yahoo Maps のク
ラス
/lib/webservice/jalan/ // じゃらんAPI
/lib/webservice/hotpeper/ // ホットペッパーAPI
/lib/mediaplayer/ // 動画再生
使い方としては、
（１）サイト全体に適用する javascript は、テーマ側で指定
（２）モジュール側は、xoops_module_header でライブラリを指定
> >（2）ライブラリの二重読み込み
> 管理画面より、読み込むライブラリ（とバージョン）を指定できるようにする。
> （2）と同様、管理画面より javascript の script を追加できるようにする。
> 追加した script は、xoops_script_header みたいな場所に書き出される
> （あるいは、xoops_module_header に追加する
モジュールを配布する時にjs・libのファイルも同梱して配布すれば大きな問題はないと思います。
以上です
氷川霧霞
命名規則は有力な候補になりそうですね(^ ^)。
> （２）モジュール側は、xoops_module_header でライブラリを指定
>
>> >（2）ライブラリの二重読み込み
>> 管理画面より、読み込むライブラリ（とバージョン）を指定できるようにする。
> と
>> >（3）サイト全体に適用する javascript
>> （2）と同様、管理画面より javascript の script を追加できるようにする。
>> 追加した script は、xoops_script_header みたいな場所に書き出される
>> （あるいは、xoops_module_header に追加する
>
> の部分で、管理画面から設定するというのは、ライブラリの管理の手間も増えるし、きちんと定義しておけば問題はないと思います。
hiro1173さんの方法（「きちんと定義して～」）だと、テーマとモジュールの
両方で同じライブラリを読み込んだ場合に問題になるんじゃないでしょうか？
たとえば、僕が作ったbizforumというモジュールではjQueryを読み込んでいます。
一方、サイト運営者が、トップページで使うためにテーマファイルに jQuery を
読み込む指定を<head>内にしたとします。
このサイトで、bizforum モジュールにアクセスすると、テーマで読み込み、
モジュールの xoops_module_header の指定で読み込み、都合2回読み
込むことになりますよね。
モジュール作者側は、テーマやブロックでどんなライブラリが読み込まれるか
分からないので定義をしっかりするだけでは解決できないような気がします。
また、テーマにjavascriptを書く人も、各モジュールでどんなライブラリが使わ
れているかを注意深く確認して書く、後からモジュールを追加するときも
新モジュールで使うライブラリがバッティングしないようにする、というのは
かなりの手間になると思います。
なので、それぞれが気にせず読み込みの指定をして、重複はLegacyなどで
うまく処理するようにしないと構築・運用が結構厳しいのではないでしょうか。
以上です。
2008/10/06 22:35 hiro1173 <in...@beabo.net>:
hiro1173
ライブラリの設置方法に関しては、Cube側で決めればモジュール側も対応してくる
と思います。
javascriptの二重読み込みの防止という目的で、氷川さんのいう手法もアリだと思い
ます。
しかし個人的には、モジュールでjavascriptを使うのは処理上必要で、モジュール
側を優先しなければ動作しなくなる事から、テーマの方が対応するべきと思います。
テーマの中で、２重定義を防止するのに、<{$xoops_dirname}>で呼び出すモジュー
ルのパスを特定して、if文で区別する事で対応が可能だと思います。
たとえば、bizforum以外で jquery-1.2.3.pack.js を実行させるには以下の様に
<{if $xoops_dirname ne 'bizforum'}>
<script type="text/javascript" src="<{$xoops_url}>/js/jQuery/
jquery-1.2.3.pack.js"></script>
<{/if}>
こういった対策方法を知ってれば、XOOPS側で自動的に対応させる必要性はあるのか
な？と思ったわけです。
javascriptのライブラリこそかなりの数もあるし、それをどう管理させて二重読み
込みを回避するのか？管理画面での管理の工数が増えることでの複雑さが増すなど
のマイナス面が出そうです。
テンプレートのif文というシンプルな手法で逃げること可能なので、本当に必要か？
と疑問に思います。
モジュール製作者は、基本的にデフォルトのテーマを対象に考えて作ればいいと思
います。
まぁ、自論なので、これがベストとは言えないかも知れませんが、私は、javascript
の二重読み込みの防止はテーマでやってます。
他の方の意見とか聞いてみたいですね。
時田正彦
時田です。
ライブラリの置き場所のということではないのですが、関連しそうなので
書いておきます。
OSCのときに、モジュールを依存関係を解決しつつ自動でアップデートしたいと
いうような話をしてまして、minahitoさんがそれはマニフェストファイル（minifest）
に依存関係を記述してある（はっきり覚えてないですがそんな趣旨のことを）
と言ってました。
例えばあるモジュールが altsys に依存していたらインストール時に自動で
altsys がインストールされるといったことです。（あくまで仮定の話です）
さっきメールを読んだら javascript のファイルも同じかもと思いました。
モジュールが依存しているライブラリをマニフェストファイルに書いておいて、
コアではそれを元に自動でファイルを読み込んでページを表示することができる
かなと。
コア側で必要なライブラリのバージョンや依存関係を把握できるので、二重読み
込みを防げますし、必要なファイルだけ読んで無駄がないといったこともいえる
かと思います。
--
時田正彦 <BQB0...@nifty.ne.jp>
http://tokita.net/
K. Ono
各種javascriptライブラリ自体をそれぞれモジュールにしてしまうという方法も
ありますね。
jQueryならjQueryモジュールとか。XCだとpreloadがあるので、preloadで
xoops_module_headerやxoops_script_header（？）に
<script src="http://xoops_url/modules/jQuery/js/jQuery.js"></script>
みたいなものをassign（またはappend）。
こうすればjavascriptライブラリ用に新たに管理機構を作る必要がなくなり
ますし、commonのようなところにわざわざ各種ライブラリを設置する
必要もなくなりますね。
この場合、現状のモジュール管理を少し改良して、モジュールの依存性も扱えるよう
にできると良いですね。例えば、bizforumモジュールはjQueryモジュールが
インストールされていないとインストールできないとか。将来的には時田さんの
言われたmanifestoで処理するのでしょうけど。。
また、現状だとリクエスト毎に各モジュールのpreloadを読み込みに行っているようです
けど、この辺りもなんらかのキャッシュ機構を作ったりした方が良いのではと思います。
氷川 霧霞
hiro1173さん、ご意見ありがとうございます(^ ^)。
> こういった対策方法を知ってれば、XOOPS側で自動的に対応させる必要性はあるのか
> な？と思ったわけです。
>
> javascriptのライブラリこそかなりの数もあるし、それをどう管理させて二重読み
> 込みを回避するのか？管理画面での管理の工数が増えることでの複雑さが増すなど
> のマイナス面が出そうです。
>
> テンプレートのif文というシンプルな手法で逃げること可能なので、本当に必要か？
> と疑問に思います。
な手法」にたいする評価の違いが意見の違いになっているのかなあ。
確かにhiro1173さんは苦もなくやれるでしょうし、僕ももちろんやれますが、
僕のモジュールを使って質問してくる人については、「できるかな～厳しそう
だなあ」という人が何人か思い浮かぶんですよ。
あと、モジュールは極力FTPでアップロードして、管理画面からインストール
したら使えるようになっていてほしいと思っていまして、「モジュールをインス
トールしたらテーマファイルを修正してください、ただしテーマで使っていな
ければその必要はありません」とかさせるのは気が引けるんですよね(^ ^;。
> 管理画面での管理の工数が増えることでの複雑さが増す
これは僕は全然実感がないのですが、hiro1173さんは複雑に感じますか。
もちろん管理画面での管理の工数は増えますが、代わりにテーマファイル
での管理の工数は無いので、どちらも同じに思えます。
現在も、METAタグなどは管理画面から入れていますが、そういった入力
フィールドが一つ増えるだけで考えていますが、テーマに直書きするのに
比べて複雑でしょうか。
以上です。
氷川 霧霞
小野さん、ありがとうございます。
をを、なんかエレガントな解決方法ですね！
でもイメージできませんでした(^ ^;ので教えてください。
jQueryモジュールというのは、javascriptファイルの置き場のために作った
ダミーモジュールみたいなのでしょうか？
それとも何か機能を持ちますか？
「preload で xoops_module_header に」というpreload ファイルは bizforum/preload
に置く、という理解であっていますか？
と、
<script src="http://xoops_url/common/js/jQuery.js"></script>
みたいなものをassign（またはappend）。
と、置き場所が違うだけ？ jQueryをモジュール化することで得られる何かを
うまく使うことを想定されていると思うのですが、すみません、そのあたりの
仕組みをもう少し教えていただけますか。
以上です。
K. Ono
> jQueryモジュールというのは、javascriptファイルの置き場のために作った
> ダミーモジュールみたいなのでしょうか？
> それとも何か機能を持ちますか？
いえ、機能は持たないと思います。持たせることもできるかもしれませんが。。
そういう意味ではダミーモジュールですが、
> 「preload で xoops_module_header に」というpreload ファイルは bizforum/preload
> に置く、という理解であっていますか？
preloadはもちろんjQuery/preloadに置きます。
すいません、僕はソースしか見ていないのですが、preloadってsettings/site_defaut.ini.phpで
[Legacy]AutoPreload=1であれば、全てのアクティブなモジュールのpreloadを読み込んでますよね？
そうであればカレントのモジュールがbizforumであっても、jQueryモジュールが有効であれば
jQuery/preloadを読み込みに行くので、preloadはjQuery/preloadに置くことになります。
>> <script src="http://xoops_url/modules/jQuery/js/jQuery.js"></script>
>> みたいなものをassign（またはappend）。
>
> と、
>
> <script src="http://xoops_url/common/js/jQuery.js"></script>
> みたいなものをassign（またはappend）。
>
> と、置き場所が違うだけ？ jQueryをモジュール化することで得られる何かを
> うまく使うことを想定されていると思うのですが、すみません、そのあたりの
> 仕組みをもう少し教えていただけますか。
はい、簡単に言えば、置き場所が違うだけになります。ただ、「jQueryが必要なモジュールは
jQueryモジュールがインストールされていないとインストールできない」のような仕組みを
現在のモジュール管理機構に付けることができれば、jQueryライブラリの重複は避けることが
できるのではないでしょうか？もちろん、モジュール側でjavascriptライブラリを用意しないことが
前提です。
K. Ono
> もちろん、モジュール側でjavascriptライブラリを用意しないことが
> 前提です。
すいません、この部分少し分かりにくかったですね。。
要は、bizforumのような、jQueryに依存しているモジュール側でjQueryライブラリを
用意しないことが前提ということです。
K. Ono
うーん、更に分かりにくくしてしまっているようですいません。
ただ、例えばbizforumとbiznewsの両方の配布パッケージにhtml/common/jQueryが有る場合に、
両モジュールをインストールしようとするユーザにとって、html/common/jQueryを上書きして
しまって良いのかどうかというのは大きな問題だと思うんです。
そういったユーザの為にも、javascriptライブラリ自体がモジュールだとそういった心配が
なくなる。bizforumとbiznewsをインストールする際に、jQueryモジュールが既に
インストールされているかどうかをチェックするだけで済む。モジュール開発者側に
とっては単純なことですが、ユーザに取っては結構大きな問題だと思うんです。
2008/10/09 20:27 K. Ono <ono...@gmail.com>:
氷川 霧霞
解説ありがとうございます、小野さん。
とりあえず、概略は理解できました(^ ^)。お手数おかけしました。
詳細についてはもう少し考えて見ます。
gus...@gmail.com
ピンポイントレスですが、以前HDのMLにおいて、PEARなどの扱いについて同様の
話題になったことがありました。
このスレッドは一通りウォッチしていたのですが、同一ライブラリのバージョン
差異などについても、検討しておいた方が良いと思います。
（最新だと動かないモジュールと、最新でしか動かないモジュールのバッティン
グなど）
モジュール同士なら、module_headerという手段もありますが、ブロックが絡ん
でくると、どこで衝突が起きるか判りませんし、何か妙案があればよいのですが。
。。
"K. Ono" <ono...@gmail.com>さんからのメールを引用します。
----------ここから原文----------
>
> 小野です。
>
> うーん、更に分かりにくくしてしまっているようですいません。
>
> ただ、例えばbizforumとbiznewsの両方の配布パッケージにhtml/common/
jQueryが有る場合に、
> 両モジュールをインストールしようとするユーザにとって、html/common/
jQueryを上書きして
> しまって良いのかどうかというのは大きな問題だと思うんです。
>
> そういったユーザの為にも、javascriptライブラリ自体がモジュールだとそう
いった心配が
> なくなる。bizforumとbiznewsをインストールする際に、jQueryモジュールが
既に
> インストールされているかどうかをチェックするだけで済む。モジュール開発
氷川 霧霞
On 10月10日, 午前2:35, gus...@gmail.com wrote:
> gusagiです。
> 差異などについても、検討しておいた方が良いと思います。
> （最新だと動かないモジュールと、最新でしか動かないモジュールのバッティン
> グなど）
諦めていました(^ ^;。
あと似たケースとして、prototype.js と jQuery の $() のバッティングもあって、
こちらの方が発生する危険性ははるかに高いですよね。
一応回避策はあるようですが、他のライブラリの組み合わせでも似たような問題は
発生するのかな。
小野さんの方法ですと、XOOPSの全てのページでライブラリを読み込む（使っていようが
いまいが）ので、必要なモジュールでのみ呼び出す方法に比べて上のような問題が
発生しやすくなってしまいますね。そこが弱点でしょうか。
（あと無駄なロードをするというのが若干気にならないでも）
今のところ、解決策なしです。
XCL 標準 Javascript ライブラリを設定してしまう、くらいでしょうか。
以上です。
nao-pon
JavaScript ライブラリのバッティング問題は、厄介ですよね。
特に、ブロックで JavaScriptライブラリを必要とする場合、読み込むものによって、即、動かなくなるケースが簡単に起こってしまうでしょ
う。
回避するには、XCL標準 JavaScript ライブラリを設定するほかないかな。と私も思います。
しかし、どのライブラリを採用するかが、難しいところですね。
モジュールで利用されているライブラリは、何が一番多いのでしょうか。
ちなみに私がいじっている xpWiki は prototype.js(1.6.0) + scriptaculous.js(1.8.0) で、ブ
ロックでもバリバリに読み込まれていますしバージョンが違うと動かなくなったりします。
K. Ono
> 小野さんの方法ですと、XOOPSの全てのページでライブラリを読み込む（使っていようが
> いまいが）ので、必要なモジュールでのみ呼び出す方法に比べて上のような問題が
> 発生しやすくなってしまいますね。そこが弱点でしょうか。
> （あと無駄なロードをするというのが若干気にならないでも）
この場合、javascriptライブラリも通常のモジュールなので、一般設定でこのライブラリを
使用するモジュールを選択できるようにするというような方法もあるかもしれないですね。
または、このモジュール自身がdelegate managerを通して独自のイベントを発生させて、
ライブラリを使用するモジュールの情報を集めて、カレントのモジュールがその中にある場合に
xoops_script_headerをセットするとか。。
無駄なロードに関しては、キャッシュヘッダをうまく利用すればリクエスト毎に
読み込むということもなくなると思うので、原則的に全てのページでxoops_script_header
にセットしても良いと思うのですが、どうなんでしょう。
各種ライブラリのバージョンの問題に関しては、例えばprototypeモジュールというのが
あって、このモジュールの各バージョンの同梱物が
prototypeモジュール v1.00
- prototype.js(1.6.0)
- scriptaculous.js(1.8.0)
prototypeモジュール v1.03
- prototype.js(1.6.0.3)
- scriptaculous.js(1.8.1)
だった場合に、xpWiki 3.71.84はprototypeモジュール1.03以上がインストール
されていないとインストールできないようにするとか。。
現行のモジュール管理を改良して、依存するモジュールと、依存するモジュールの
最低バージョンのチェックが行えるようになると良さそうですね。ついでにPHPのバージョン
チェックとかも。。
Xiggでも各種javascriptライブラリ等をそれぞれプラグインとしているのですが、
プラグインのインストール時に上記チェックを行うようにしています。ただ、XOOPSの
モジュールのバージョン形式だと単純にversion_compare()とはいかないのが面倒ですけど。
あと、jQuery/prototypeの$()のバッティングの問題とかは、XCに限った話だと思わないので、
各ライブラリの作者に掛け合うしかなさそうですね^^;
氷川 霧霞
> nao-pon さん
ご無沙汰してます (^ ^)
> 回避するには、XCL標準 JavaScript ライブラリを設定するほかないかな。と私も思います。
> しかし、どのライブラリを採用するかが、難しいところですね。
> モジュールで利用されているライブラリは、何が一番多いのでしょうか。
これからは jQuery の時代ですよっ！（笑）
見てきた中だと、やはり prototype.js が多いのかなあ。d3pipes もそうですしね。
＞ono さん
> または、このモジュール自身がdelegate managerを通して独自のイベントを発生させて、
> ライブラリを使用するモジュールの情報を集めて、カレントのモジュールがその中にある場合に
> xoops_script_headerをセットするとか。。
ってこれだと、
> こうすればjavascriptライブラリ用に新たに管理機構を作る必要がなくなり
> ますし、commonのようなところにわざわざ各種ライブラリを設置する
> 必要もなくなりますね。
という当初のシンプルな解決策からは外れていってしまいますね。
K. Ono
>> こうすればjavascriptライブラリ用に新たに管理機構を作る必要がなくなり
>> ますし、commonのようなところにわざわざ各種ライブラリを設置する
>> 必要もなくなりますね。
>
> という当初のシンプルな解決策からは外れていってしまいますね。
ま、どうしてもシンプルにということであれば、原則的に全てのページで
xoops_script_headerに書き込んで、無駄なロードはキャッシュヘッダで
処理するような感じですかね。
>> または、このモジュール自身がdelegate managerを通して独自のイベントを発生させて、
>> ライブラリを使用するモジュールの情報を集めて、カレントのモジュールがその中にある場合に
>> xoops_script_headerをセットするとか。。
も、それこそpreloadに数行追加するだけで済むと思いますが、ブロックで
ライブラリが必要な場合も考慮すると良い案ではないかもしれないですね。