FuelPHP、MVCと自動生成とテンプレートと

FuelPHPはビュー周りは、良く言えば柔軟性が高い、悪く言えば統一感がないですね。

MVCとテンプレートエンジン

MVCはアプリケーションの構造で、モデル、ビュー、コントローラーを分離し、それぞれの独立性とメンテナンス性を高める目的があります。この概念が宣伝されていた初期の頃、頻繁に例として出されていたのはビューを取り替えて、同じ出力をWebにも、画面にもプリントアウトも出来るという説明でした。それと、モデルはファイルでもDBでも切り替えられるという説明もありましたね。

そして、コードを書く人と、デザインをする人が分かれだした頃、PHPでもこの概念のビューの分離が取り上げられ、モデルとコントローラーはプログラマー（コーダー）が担当、ビューはデザイナーが担当と仕事を分割できるため、テンプレートエンジンが受け入れられてきました。

その後、MVCを分離したフレームワークが流行りだし、ビューだけを分離するという視点からはテンプレートエンジンを使用する必要はなくなりましたが、やはり既に身につけたスキルを活かしたい、慣れているものを使いたい、既存のコードを活かしたいという欲求もあり、ビューにフレームワークを取り入れる工夫がユーザーの手によって行われました。

FuelPHPはその欲求を最初から満たしています。テンプレートの拡張子によりビューを取り扱うテンプレートエンジンを切り分けるという、斬新なアイデアです。

小さなフレームワークでは既存の小さなテンプレートエンジンを取り入れているものもありますが、使い分け可能にしているというのは、珍しいフレームワークですね。

ただし、もしあなたが私と同様にテンプレートエンジンに親しんでいなくても、改めて勉強する必要はありません。もともとPHPは固定されたHTMLに、柔軟なコードを挿入するために、開発され、使用されたようなものです。デフォルトはphpを拡張子としたPHPコードがビューとなります。

MVCにHがついてHMVC

Hは「はい、荒木かい？」、いいやハイアラキカルの略です。階層的なという意味です。

この階層的の意味を取り違えている説明が検索するとありました。私もそれを読んでいたため、理解が遅れました。MVCのディレクトリー構造を階層的に持てる仕組みがHMVCだと書かれていました。

そうではないんですね。MVCで一つの出力、それをFuelPHPのドキュメント中ではウィジェットと呼んでいますが、その中から、別のウィジェットを呼び出して表示することができる。つまり、階層的に表示できるため、Hが付いているわけです。（正確に言えば、コントローラーから別のコントローラーを呼び出せるという意味です。良い説明がありました。こちらを御覧ください。）

HMVCにするためには、当然MVCのディレクトリー構造は各ウィジェット毎に独立していなくてはなりません。それが、FulePHPにおけるモジュールというわけです。

Vにはテーマクラスも

cssやjs、画像ファイルはassetsというフォルダー下に入っています。これが、私は気に入らないところでした。

また、assetクラスという、css、js、画像ファイルを扱うクラスがわざわざ存在していることも、謎でした。

今回やっと、意義が理解できました。themeクラスが作成されたからです。ドキュメントもやっと書かれたようです。

テーマはCMSやブログシステムでもお馴染みの、テーマとか、テンプレートとか呼ばれるやつです。

テーマはデザインつまり見た目の切り替えに使用される仕組みです。同じ出力をどう見せるかを切り替えられるようにするクラスです。

切り替えられるようにするために、ビューファイルと、css、js、画像ファイルをテーマ毎に独立させ、切り替える方法が一般的です。themeクラスではその仕組みを実現しています。

そして、このテーマクラスにも、もちろんFuelPHPの拡張子によるテンプレートエンジンの使い分けは使用出来ます。

Fieldsetクラス

ここまでは、各クラスを独立させるという視点から導入された仕組み達で一貫性もあります。

Fieldsetクラスは利便性のため、せっかく用意されたこうしたコンセプトとは別物になっています。

コントローラー中に記述されているバリデーションはフォームの入力フィールドに対して行います。そこには、フィールド名と、通常はlabelで付けられるフィールドの表示文字列が指定されています。

ここに入力項目の種類（text、password、selectなど）と必要なデーターを渡してあげれば、html要素を出力する情報は集まります。それならば、フォームの内容を自動的に生成してあげようという仕組みです。

フォームが生成されるわけですから、ビューのコードは減ります。コントローラーのコードがやや増える程度です。

更に、モデル中でORMを使用している場合、そのモデルの中で、フォームの出力を定義できます。Fieldsetクラスに、そのモデルを指定することで、記述されたフォームを生成できます。

便利です。本当に。

しかし、当然ながら、自動的に生成されるフォームですので、制限があります。バリデーションにrequiredを指定すると、項目名の横に*が自動的に付きます。（これは、この手の自動生成が出てきた約10年くらい前から、わかりやすいという声と、何で余計なことをするのかという声が、毎回湧き上がるのです。）フォームはテーブルで組まれます。required項目にはhtml5のrequired="required"が挿入されます。

オプションか、設定ファイルでこれらは柔軟に変更できるのかと思いましたが、今のところできないようです。「規約よりも設定」のFuelPHPですから、将来のバージョンでは自在に変更できるようになることを祈りましょう。

（追記：required以外は変更可能であると教えて頂きました。Google Group:FuelPHPを御覧ください。コンフィグファイルはform.phpです。)

こうしたデザインが固定されるという点以外に、コンセプトとしては、MVCとは真逆になっていることに気づきましたか？ビューの内容をコントローラーに、そしてモデルに振り分けています。MVCが独立しなくなります。

まあ、デザイン重視の方は利用しないでしょうね。それとプログラムとデザインを分けたいときにも微妙ですね。

使い分けるポイントは利便性になるでしょう。個人で開発し、MVCの独立は、コーディング全体として、ちょっとわかりやすくなる程度だと考えている人で、お手軽に利用したい方には、嬉しいでしょう。便利ですよ。確かに。

私？私は、小さく単純なツール作るときのみ利用します。でも、それならスキャフォールディング使ったほうがよさそうですね。細かい制御ができなくなりますからね。それと、html5のバリデーションはブラウザ対応考えると、一般向けに利用できるには後まだ数年掛かりそうですし、機能も十分でないので、まだJavascriptのお世話になりそうですから、FuelPHPのバリデーションを継承して、ちょっとした仕組み作ったばかりなんです。それはValidationクラスを拡張しています。Fieldsetも考えたのですが、複雑になりそうなので、止めました。どちらかと言えば、デザイン的な自由さも確保しておきたい人間なんです。

（追記、HMVCはkonahaから、Fieldsetのフォーム自動生成はYiiからのパクリじゃないかなと思います。さすが、他のフレームワークの良いところを頂いたFuelPHPです。悪いところも、頂いちゃったかな？自動生成はYiiの日本人ユーザーさんたちも、意義がわからないと言っているようです。）