フレームワーク「MagicWeapon」コミュの[思考実験]MWのMVC再考察

現状、Modelにちょっといろいろよりすぎててぶっちゃけキショい。
理想としては
・Cが振り分け
・Mはin構造体受け取って処理してout構造体に情報を出す
・Vは設定にしたがってout構造体を適切なテンプレートにぶつけて出力
ってのが役割分担として多分適切。
注：厳密には構造体に入りにくい(無理==不可能じゃない。無茶==面倒なだけ：データがloopしてる中でloopしてるとか)情報もあるがまぁおいといて。

それを基準に考えると、mapファイルは多分

コマンド: in構造体定義, modelクラス定義, out構造体定義, テンプレートファイル定義(, エラー時テンプレートファイル定義)

って書式が妥当なはず。
ただ。in構造体定義とmodelクラス定義は別々に定義してもあんまり意味がないとおもわれる。
ってのが
・ンなものはmodelクラスが知ってればいいから
ってわけで

コマンド: modelクラス定義(include in構造体定義), out構造体定義, テンプレートファイル定義(, エラー時テンプレートファイル定義)

となる。
ここでちょいと
・通常のブラウジングなWebとWeb APIの諸入力系列(SOAPとかRESTとかその他もろもろ)を考察。
cgi_requestをもういっちょラッピングすればよいっていうかそのまま？
ようは
ヴァリュ〜 = $obj->find(きー);
で情報とれればいいでしょ？ って程度に雑に(笑
Cookieの扱いが微妙だなぁまぁあれはよし。っつのが、ほかのすべてが「contents body」であるのに対してCookieは「HTTP
header」なので、性質が違う。
なので、Cookieは常にCookieとして扱えるはずなので。HTTPである限り。

この時点でとりあえず懸念してた一つである「Web API対応」が近づく。

ちゅぎ。
out構造体定義。…各Modelごとに作るのかなり厄介だなぁと。ぶっちゃけ面倒。
…で、ふと気づいた。
「conv インスタンス使えるじゃん？」

convインスタンスって、とりあえず情報として「loopでloopなネスト情報含めて」置換するための情報は全部持ってる(正確には情報じゃなくて情報造るためのclassだったりするかのせいもあるけどそれを含めて)。
一応弁明(誰に何を？)。
Smartyインスタンスも基本同じ状況であると捕らえてよいとおもう。

で。
だとすると、convインスタンス渡せばいいだけなら、modelで設定してmodelから取りだしゃいいよね？

とするとだ。
コマンド: modelクラス定義(include in構造体定義), (out構造体定義 はconvを用いる,)
テンプレートファイル定義(, エラー時テンプレートファイル定義)
となる。
清書。
コマンド: modelクラス定義, テンプレートファイル定義(, エラー時テンプレートファイル定義)

すっきり。

現状、ちと見直しているMWで、base_modelにこげな機能を入れてる(ほとんど「お便利class化」してるがまぁいいや)。
public function make_body_with_conv($tmp_filename)
{
$this->set_body($this->get_conv()->conv(file_util::read_file($this->get_config()->find("template_dir")
. $tmp_filename)));
return true;
}

似たようなクラスはみんな作ってるっしょ？

となるとだ。
set_bodyにちょっと小細工をすると多分下位互換。
具体的には。

・true_viewフラグ。でふぉはon
・set_bodyのときはtrue_viewフラグ = off

これがmodel側の挙動。
view側は
・true_viewフラグがonならあらかじめ設定されているconvインスタンス使って設定ファイルのテンプレートにぶつけて出力
・true_viewフラグがoffならset_bodyの中身を出力

こんな感じかな？
後は…view側を少しリッチにしてみよう今度。
具体的には、とりあえず携帯。絵文字対応とかその辺が面倒なので、そゆのはviewに処理させたい。

んむおもったよりきれいにまとまってみた。

もともと、ModelでHTMLを生成するのはかなり気にしてた。
http://d.hatena.ne.jp/gallu/20060414/p2
を参照。

このやり方だと
・同一のModelで(ようは実装せずに)
・テンプレートファイル名＆コマンド名かえるだけでブラウジングとWeb APIにダブル対応
が楽にできる…はづ。
実際には。「ブラウジングの画面の情報量 == Web APIで復帰するXMLの情報量」になることは割合に少ないとおもうんだけど。
それにしても、engineとかでちゃんと切り出して部品化すれば、二回書く無駄は防げるはづ。

以上思考実験終了。