フレームワーク、パスとパッケージとルーティング

FuelPHPに限らず、フレームワークにパッケージ、プラグインなどの拡張を作ろうとするならパスも考えておかなくてはならないという、当たり前のお話。

まだFuelPHPが1.1RCで、よく分かりもせずGithubから開発版をクローンして、それを基に組み始めました。

Assetクラスがどうも上手く動かず、やっと動いたら、変な数字が勝手に後ろにつく。今はこの数字はキャッシュだと分かりますが、指定もしないのに数字が後ろについたらバグだと思うのは人情ですよね。マニュアルの表記と異なっていましたことですし。

それで、Assetクラスを諦め、例えば”/css/default.css"と指定したのに読み込めず、"./css/default.css"とか色々試してだめで、結局完全な絶対パス"http://domain.com/css/default.css"と書いて、やっと読み込め、この件は忘れていました。

いま、落ち着いて考えれば、FuelPHPはサブフォルダーに解凍したものをポンとおいてあるだけですので、"/fulephp/public/css/default.css"と書けば、読み込めたわけです。

"../../css/default.css"という書き方は絶対ダメですね。フレームワークを使用する利点の一つは、ルーティングについて仕組みを自分で考えなくていいというものがあります。実際、パブリックエリアのindex.phpからの相対位置としてパスを指定しがちですが、実際はブラウザ側で呼び出すURLからの相対位置になります。アプリケーションによって生成されるURLはhttp://domain.comかも知れないし、http://domain.com/aaa/bbb/ccc/ddd/....かも知れません。相対位置では一定の場所が指し示されません。

まあ、ここまでがアプリを作成する人にとってはおなじみであり、デザイナーさんとかでちょっといじるだけの人には「フレームワーク使わないときは相対指定、フレームワーク使うときは絶対指定か、ルートからの位置で指定する」のを守ることだけを覚えていればいいだけの話ですね。

フレームワークには、指定されるルーティングがコロコロ変わることを前提として、また動的にフレームワークの位置が変化しても大丈夫なように、自動的にパスを生成してくれる仕組みや、ルートまでの位置を示す関数なり、変数が用意されています。FuelPHPであれば、url_base、Uri::base()、Uri::create()に当たります。これらを使えば、アプリケーションの位置がどこにあろうと、フレームワークに任せられます。

今回はまったのはFuelPHPで作成したTinyMCEのパッケージです。パッケージにしたため、FuelPHPがルートディレクトリー直下であろうと、サブディレクトリーであろうと、動作しなくてはなりません。当初はAssetクラスの使用を考えていましたが、当時はまだ不安定でした。そこで、Uri::base(false)を頭につけ、TinyMCEのスクリプトを指定しました。

これは問題なく動いたのですが、そのTinyMCEに読み込ませるcssファイルの指定がうまくいきません。指定はJavascriptとして生成します。サンプルの指定位置とドキュメントには相対位置で書かれていました。しばらく考え、色々試し、よくよく考えた結果、ページのURLが何であろうとも関係なく、TinyMCEはhttp://...と絶対パスで指定してあり、ならば、cssファイルも絶対パスで指定できれば問題はありません。TinyMCEが絶対パスを受け付けてくれるかなと思いましたが、大丈夫でした。そこで、TinyMCEパッケージのコンフィグファイルは、FuelPHPのドキュメントルートからの位置を'css/context.css'と指定してもらい、スクリプトの生成時に絶対パスを指定するように修正しました。

TinyMCEのサンプルプログラム、そしてドキュメントは通常のhtmlファイルを想定して書かれています。通常のhtmlファイルであれば、絶対パスで書くことはできません。スクリプトの位置は、そのhtmlファイルからの相対位置で書きます。そして、TinyMCEに指定するcssファイルの位置も、htmlファイルからの相対位置です。ルーティングを自在に指定できるフレームワークを前提に書かれているわけではありません。

クリアな頭で、分かってしまえば、当然なのですが、はまっているときには全然気が付きませんでした。まあ、よくあることですね。