ログイン・ログアウトの実装を考えていたとき。
「・・・しまった。setup-HOOKでLocationなどでリダイレクトしたとき、Flow制御全体をスキップする機能、実装してねぇ・・・。」
かくして、wipeout()が実装された。
setup-HOOKに、
function setup_check_login_redirect($hook, &$runner) {
if ( !Foo_Bar::isLogined() ) {
header("Location: http://....");
$runner->wipeout();
}
}
とかをpushして使います。
ちょっとまとめてみます。
抑止力: wipeout() >> skipPage()
下の表の記号は次のような意味です。
○:制御メソッドの呼び出しにかかわらず、実行されます。 ×:制御メソッドを呼び出すことで、実行されません。 ▼:呼び出しポイント
| 制御メソッド→ | wipeout() | skipPage() | (Renderer無効化) |
|---|---|---|---|
| setup-HOOK | ▼ | ▼ | ○ |
| Barrier | × | ▼ | ○ |
| Guard | × | ▼ | ○ |
| Event | × | ▼ | ○ |
| Page | × | × | ▼(*1) |
| Renderer | × | × | × |
| terminate-HOOK | ○ | ○ | ○ |
以下余談、というか頭の中の妄想を踏まえて。
これで一通りlogin/logoutは固まったかな・・・。
結局、画面遷移の好みに応じて千差万別な形態がありうるわけで。
今のところ、ActorにAbstractを用意したり、同じフローでがりがり書いたり、
ログイン処理専用のフローを別に用意してsetupHOOKでリダイレクトかけたり、といろいろできる。
で、いろいろできるようにしておくのがフレームワークの仕事。
可能性、abilityだけは確保しておく。
実装を提供してそれを狭めてしまうのは、論外。
・・・ずいぶん風変わりなポリシーだけどね。でも、それがPokoXから続く、Xhwlayのポリシー。自由は、全て開発者の手に。フレームワークにより縛らない。
う~~ん・・・本末転倒。