わざわざ残す必要もないことを整理とか気にせずに吐き出していく。そんな空間。

fuelphpのViewの何か今ひとつ物足りない感をなんとかしてみた

PHP

そんな大した話ではないんですがね。

fuelphpのView機能。スキニーコントローラ強依存症患者な自分としてはかなり嬉しい感じなんですが,やっぱりまだひとつ物足りない感が

fuelphpのView

　fuelphpのViewは素晴らしい。なんせViewクラス。ViewはControllerのいち機能、ではない。fuelにおいてはViewとControllerに全く何の関連性もない。それだけでも十分に素晴らしい。

　オートローダシステムを利用して静的クラスの変数にどこからでもガシガシ値を出し入れ出来たり(んでもこれってGlobal変数と何が違うの?)、利便性はきっちりと確保されたまま、ControllerとViewとの切り離しに見事成功している。もう$thisじゃない(←これ重要)。

　んなもんだからViewModelの実装もほんとに簡単。ViewModelクラスってのも提供されてて,これが使いやすいかはさておき,そんなもんが無くとも自力でViewModelを実装できるわけで,こうした設計はスキニーコントローラ強依存症には非常に助かる所。

fuelphpのViewの残念な所

　fuelphpのViewクラスには,レイアウトの機能がない。要はViewクラスってのは単一のテンプレートファイルのレンダラーとして設計されている。メインのレイアウトファイルに,コントローラアクション単位のテンプレートファイルを割り当てて…みたいなViewの階層化、は複数のViewクラス(のオブジェクト)を組み合わせて実現することになる。これが微妙に厄介だ。

　一応TemplateControllerなんてものが用意されてはいるのだが、これはController。これだと意味が無い。なんせまた例によって$thisだ。Controller内で$this->viewとか書かなきゃならない。これだけは本当に避けたい。このへんが共感できるかはともかくとして,せっかくViewとControllerを分離したのに,なぜまたControllerにView処理の手綱を渡さなきゃならんのか、と言う話。

　しかもそもそもViewクラスは単一テンプレートファイルのレンダラーとして設計されているために親レイアウト->子レイアウトの形でアクセスしなければならない。これも非常に気持ち悪い。データの設計的に理解できなくはないんだが,使う側の心理としては子レイアウト->親レイアウトのデータ構造が好ましいと思う。親レイアウト経由でしか,子レイアウトにアクセス出来ないのは煩雑だし、親レイアウトは願わくば子レイアウトのプロパティ的存在であって欲しい。

なんとかしてみた。

　fuelphpを触りだすとそのへんの所がどうしても気になる。というかまぁ正直どっちでもいいっちゃどっちでもいいんだが,なんとなくモヤモヤしたまま進めるのも気が乗らない。

　第一,新しくfuelphpでプロジェクトを構築し始める度にこんなしょうもない問題で悩んで作業が止まるのは非常にもったいないので,じゃあいっそ書いてやればいい,って事になってざっと書いてみた。

https://gist.github.com/mikakane/5473969

Layoutクラス、と言う形で実装。Layoutクラスは継承関係のない普通のクラスで,get/setで静的クラス変数に値を格納できるようになっている。これが親レイアウトで利用可能となる変数となる。あと個人的にはsetに加えて配列要素に値を追加するaddというメソドの存在。これは非常に便利なんじゃないかって思っている。

　一応,一般的なViewというものの形に合わせてLayout::setした値は、親レイアウトファイル内で$var形式のアクセスが可能となっているが,基本的にはどこからでもLayout::getでアクセス可能なので,これは正直必要ないんじゃないかって思っている。

　とにかくこれで、なんとかもやもやが解消された、と言う感じ。オープンソースなんだからプルリクエストしてみようかとも思ったけど,正直必要性を全く感じないし,オートローダなのにクラス2個定義してるとか反則だしでなんか気が乗らなかったため、ブログのネタとして消化することにした。

　もっと細かい事を言い出せば,「なんでset_filenameメソドでviewsディレクトリをハードコードしたのか(extensionはクラス変数なのに…)」とか色々とあるんだけれどもそれはまた別の機会にでも。