浮気をしてみました
あ、人間ではないです。guesswork classic 0.0.2を見てました。使う方もシンプルであるなら実装もシンプルで読みやすかったです。見たところマニュアルでは説明されていない機能もあったりしますね。処理の流れはMaple同様、Controller(のprcessメソッド)に集約されていてほぼ下のような流れのようです。
- アクション名の取得
- (使用する場合)セッションの開始
- ビューの設定を取得
- init()メソッドの実行&パラメータをプロパティにセット
- BeforeFilterの実行
- AroundFilterの前半(before()メソッド)を実行
- 「prepare+アクション名」メソッド(ビジネスロジックの前処理)実行
- 「execute+アクション名」メソッド(ビジネスロジック)実行
- ビューの描画
- AroundFilterの後半(after()メソッド)を実行
- AfterFilterの実行
という感じです。
面白いと思ったのは、フィルタが2種類に分かれています。
- Mapleのようにプリフィルタ&ポストフィルタのように呼ばれるフィルタ(AroundFilter)
- 呼ばれる位置が固定される(ビジネスロジックの前「BeforeFilter」か後「AfterFilter」)フィルタ
あとは、init()とprepare()の存在でしょうか?
必要がないのかもしれませんが、prepare()があるならバランス的にpost処理もあってもいいのかな?と思いました。意図があるんだと思いますが、BeforeFilterとAfterFilterがその役割を担ってもいいのかな?とも思いました。確かに分けた方がすっきりと判りやすいんです。
fireFlash()とclearFlash()は意図が読めていません・・・。
render系はまだ実装途中のような印象でした。
若干考えてみたこと。
DefaultView-init
$this->templatesDir = rtrim($config['_gw_template_templates_dir'], DIRECTORY_SEPARATOR);
一行でいけないでしょうか?
DefaultViewで以下を追加し、
var $varname = 'm'; function setVarName($varname) { $this->varname = $varname; }
DefaultView-processで
${$this->varname} =& new DefaultViewModel;
としてビューで任意の変数名が使えるかも?
Loggerでis〜メソッドがあるので
if ($this->level > GW_LOG_TRACE) { ↓ if (!$this->isTrace() {
Controller-render
$this->_gw_view->process($template_path, $model);
最後ののところですが、ここを通るとき$template_pathが設定されていないような気が・・・
実際に使用するときにはControllerクラスを継承しますが、アプリケーションに共通の設定(templateとか)もありますので、1つ間にその部分を指定するクラスを作成してそれを継承して使う形になるんだろうなぁと思ってます。これはフレームワークが気にする必要はないですね。使う側が考えることですね。
今日見たら0.0.3が出てましたね・・・