前代未聞の退会手続きゲーム『ゼロシキからの脱出』/ゲーム情報ポータル：ジーパラドットコム
某所にてネタをいただいてきた。
これはいいところに目をつけたなあと感心です。
ケータイの会員登録って、簡単にできるくせに、退会となると、故意か知らないが、わかりにくい場所にリンクがあったり、リンクをクリックしても何段も手続きがあったり。
ひどいのになると、2，3段先で「メールだけの解除はできません」とか出てくる。メールじゃなくて全部やめたいんだっつーの。
そういうのがあると、運営会社調べて、そこが提供してるサービスは全部ブラックリストのメモに貼り付けるもんね。
と言うわけで、今夜にでも上のサイトを見てみるとしよう。
某所にてネタをいただいてきた。
これはいいところに目をつけたなあと感心です。
ケータイの会員登録って、簡単にできるくせに、退会となると、故意か知らないが、わかりにくい場所にリンクがあったり、リンクをクリックしても何段も手続きがあったり。
ひどいのになると、2，3段先で「メールだけの解除はできません」とか出てくる。メールじゃなくて全部やめたいんだっつーの。
そういうのがあると、運営会社調べて、そこが提供してるサービスは全部ブラックリストのメモに貼り付けるもんね。
と言うわけで、今夜にでも上のサイトを見てみるとしよう。
Cakeで認証処理するのに、AppController に 認証用のコンポーネントを読み込んで処理させてるんだが、結局認証するためには利用者のモデルクラスを経由してユーザIDやらパスワードその他の属性情報を引っ張ってくることになる。
Controller → AuthComponent
として簡潔に書きたかったところが、
Controller → AuthComponent → UserModel
となってきたところ。
さらに認証後の画面遷移先をユーザの属性によって変えたいとか思うと、Authコンポーネントで書いても、User モデル側で書いても、別にどちらでも書けるから、果たしてどっちに書いたものかと悩む。
論理的に役割をきちんと分けるには、DB アクセスが発生するようなものは User モデルクラスに集約した方が良さそうだが、じゃあ、認証そのものの仕組みも User モデルクラスで実装すべきじゃないの？ となってきてしまった。
Controller → UserModel
と言う形に。
ただ、認証通過後には Cookie に値をセットしたいとかあるので、そこらへんは User モデルの役目でもなさそうだ。
と言うことで、HTTP リクエストに関する処理、Cookie 送出に関する部分を Auth コンポーネントにお願いして、利用者の属性全般を User モデルクラスに任せるようにした。
これでいいのかなあ。
自由に書ける分だけ、こういう分担にわかりやすい基準がないと迷うなあ。
Controller → AuthComponent
として簡潔に書きたかったところが、
Controller → AuthComponent → UserModel
となってきたところ。
さらに認証後の画面遷移先をユーザの属性によって変えたいとか思うと、Authコンポーネントで書いても、User モデル側で書いても、別にどちらでも書けるから、果たしてどっちに書いたものかと悩む。
論理的に役割をきちんと分けるには、DB アクセスが発生するようなものは User モデルクラスに集約した方が良さそうだが、じゃあ、認証そのものの仕組みも User モデルクラスで実装すべきじゃないの？ となってきてしまった。
Controller → UserModel
と言う形に。
ただ、認証通過後には Cookie に値をセットしたいとかあるので、そこらへんは User モデルの役目でもなさそうだ。
と言うことで、HTTP リクエストに関する処理、Cookie 送出に関する部分を Auth コンポーネントにお願いして、利用者の属性全般を User モデルクラスに任せるようにした。
これでいいのかなあ。
自由に書ける分だけ、こういう分担にわかりやすい基準がないと迷うなあ。