自由度

何らかの規制に従って保守性を高める。
自由度を高めれば高めるほど後から見づらくなる。

100%見づらくなるわけじゃないのか。
気を付けて書かないと見づらくなるんだ。

元々PHPは自由に書けて見やすい。
簡単にプログラムするための枠組を作ったからと言って、元々の良さを壊すわけにはいかない。

難しいな・・。

取り敢えずログイン画面がやっと出来た。何日かかったんだ一体。。。
ログイン済かのチェックもIDとパスワードからログインする処理も同じクラスで扱うようにした。
要するにログインを処理するというクラスを作って、それがログイン済判定のフィルタの役割になったりログインやログアウト自体の処理をする役割になったりする。

アクションとフィルタの概念はあるけど、同じ処理は同じクラスにまとめるという基本に則ってみた。

しかし・・今のところは何とも分からない。
これがソースコードが増えると分かりやすくなるか分かりにくくなるか。

LoginUserクラスのログイン済判定（未ログイン） => ログインフォーム表示
LoginUserクラスのログイン処理                 => （アクション転送）ログイン後ページ表示
LoginUserクラスのログイン済判定（ログイン済） => ログイン後ページ表示

何だか無駄な部分があるような・・。
ちょっと寝かせておいてまた後で考えよう。

処理毎にクラスか関数か

そうか。
http://d.hatena.ne.jp/hawkring/20050817

2つの別の用途に用いられるアクションに対して、フィルタ・チェーンの構造は1種類しかない。一方の処理のために登録されたフィルタが、もう一方の処理に悪影響を及ぼさないことを保証するのは容易ではない（Validateはまさにこれだ）。

なんだかしっくりこなかった理由はこれか。

さっき書いた処理では、フォームからの入力でログインを実行する場合

グローバルフィルタクラス->グローバルアクションフィルタ
ログインクラス          ->ログイン実行フィルタ
ログインクラス          ->ログインフィルタ ※
ログインクラス          ->ログイン実行関数
コントローラ            ->アクション転送
グローバルフィルタクラス->グローバルアクションフィルタ
ログインクラス          ->ログインフィルタ
ログインクラス          ->表示関数
ビュークラス           ・・・

となっている。
ここの ※ のところが問題なのか・・。

今回はログイン処理の後アクションをもう一度実行してるから表示のための（と思って最初は作った）※は意味がないけど、ログイン実行関数の後にそのままビューに行くとしたら※は実行しなければいけない。

うーん・・・ゆっくり考えよう。。