CakePHP の Configure クラスで最も悩ましい点を解決する方法 #cakeadvent2012

cakephp_logo

CakePHP Advent Calendar 2012 17日目の記事です。

CakePHP 使いのみなさんこんにちは。
一番好きなクラスは何ですか?
もちろん Configure ですね。

Configure はできる子

Configure は便利ですね。

値だけじゃなくて配列も格納できるし

Configure::write('User', array(
	'name' => 'msng',
	'url'  => 'http://www.msng.info/'
));

格納された配列の要素をドット区切りで指定して書きかえたり

Configure::write('User.name', 'msng0413');

直接呼び出したり

echo Configure::read('User.url');

かなり自由にアクセスできて便利。

しかも Cake にアクセスがあったとき最初に呼び出される
コアの方の bootstrap (/lib/Cake/bootstrap.php) でロードされるので

App::uses('Configure', 'Core');

コントローラだろうがモデルだろうがビューだろうが
もう Cake アプリケーション内のおおよそ全ての場所で利用できます。

なので AppController で環境に応じた値をセットしておいて

Configure::write('lang', 'ja');

それをビューで利用して表示を出し分けるなんてことも簡単ですね。

echo $user['User'][Configure::read('lang') . '_name'];

けどひとつ困ったことがあります。

長い

長いんですよ名前が。Configure.
クラス名だけでも9文字あって、その後に read() やら write() やら続く。

Configure されたいろんな値を組み合わせて使うときなんて
もうソースコード内がコンフィギャーコンフィギャーばっかりで
他の要素が目立ちにくくなるしやたらと折り返しは増えるしで
アンリーダブルなことこの上ない。

なので Configure をもうちょっと短い名前にしてみました。

C にしてみる

app/Config/bootstrap.php あたりに
こんなことを書いてみます。

class C extends Configure {}

これで Configure を継承した C クラスができました。

短い。

echo $user['User'][C::read('lang') . '_name'];

名前が気に入らない場合

C というクラス名が気に入らない。
そうでしょうそうでしょう。
これじゃさすがに何だかわからないし
どうかしたら C 言語を呼び出すライブラリかと思われちゃうかもしれない。

だったらこれぐらいでどうでしょう。

class Conf extends Configure {}

これでも名前の長さは半分以下です。

逆に「C::read() ですら長いわ!」という場合
もうこうしちゃいますか。

class Conf extends Configure {
	public static function r($var = null) {
		return parent::read($var);
	}

	public static function w($config, $value = null) {
		return parent::write($config, $value);
	}
}

C::w('hoge', 'piyo'); で書けるし
C::r('hoge') で呼べます。
いくらなんでもこれはやり過ぎな気がするけど。

Configure と併用できる

フレームワーク内で勝手な名前のクラスを作ってコアクラスと同じ動作をさせると
コアライブラリやプラグインとの値の受け渡しがうまくいかなくなるんじゃないか
と思ったんですけど、たぶん大丈夫。

Configure クラスで設定した値は
Configurestatic プロパティ $_values に格納されていて、
これは新しく作った C クラスにも同じく継承されます。

Configure で保存した値を C で取り出したり
C で書きかえた値を Configure で読み出したり
どちらの方向へも反映されるので、両者は併用可能ですね。

導入は慎重に

この C (や Conf) は
中身こそ Configure だけど俺クラスには違いないので
いきなり導入したら他の人を混乱させてしまうかもしれません。

ひとりで作ってひとりでメンテナンスすることが決まっているとか
そのプロジェクトでコードに触れる人全員が把握してるとか
何かそういう前提がない場合はどっかでトラブルになりそうなので
あまり本気で取り組まない方がいいです。

  • このエントリーをはてなブックマークに追加