というかついさっきpushした。互換性残せた部分もあったけど、使ってる人いないと思うのと邪魔になるのでがっつり変えた。ちょっとまだふわふわしてる。
Malts
1. routesの廃止
1
2
3
4
5
| # 今まで
sub startup {
my $r = $self->routes('RSimple');
$r->connect('/' => {...});
} |
Mojoliciousみたいな感じにしてたけど、メリットが一切感じられなかったので変更。
Amon2っぽい感じになりました。
1
2
3
4
5
6
7
8
9
10
11
| package MyApp::Web;
use MyApp::Web::Dispatcher;
sub dispatch {
my $self = shift;
MyApp::Web::Dispaycher->dispatch($self) or $self->create_response(404, [], ['not not found!']);
}
package MyApp::Web::Dispatcher;
use Malts::Web::Router::Simple;
get '/' => 'Root#index'; |
orで色々変更出来て便利ですね。Amon2とほぼ一緒だけど動作は若干違う。
2. app_base_classは指定が必須に
別に使わないならいいのだけど、これがundefだとエラーが出るメソッドとかあります。
そういう時はエラーメッセージを出すようにしてるけど、忘れてるところがあったらすんまへん。
1
2
3
| package MyApp;
use parent 'Malts';
sub app_base_class { 'MyApp' } |
変更した理由としては、自動で作ったやつをキャッシュしてたんだけどそれが無駄だなーって思ったのと、Controllerでapp_base_classを初めて呼ぶと仕様上おかしい感じになるのでそれがわかりづらいなと思った。わざわざ指定するのはちょっとめんどいけど、どうせスケルトン作成で出来るし、アプリ側で指定してしまえば多分早いし分かりやすいのでそれでいいやってなった。
3. app_classの削除
ref($self);するだけとか必要ねえなと思った。
4. ok, not_foundメソッドの削除
結構便利でがっつり使ってたんだけど、okとかにすると他のエラーの時とか分かりにくいなって思った。
res_200とかres_404とか別の形で提供するのではないかと思われる。
5. responseメソッド削除
dispatchがresponseを必ず返せばいいだけなので不必要になった。
6. new_responseメソッド削除
responseをキャッシュしないので、不必要になった。
7. 5.10.1以上で動作する
state使い始めてる。5.8.xはレガシー！って事でいいのではないでしょうか。
8. Malts->context, Malts->set_contextの削除
使わないようにしたので削除。モデルで使われたらやだもん。
9. encodingをMalts::Utilでするようにした
Malts->encodingはただのショートカットになりました。
10. configはScope::Containerを使う
Config::ENVを使おうか悩んだのだけど、設定ファイルを動的に変更可能なら1リクエストに1回設定ファイルを読み込んだ方がいいだろうって思ってScope::Containerを使うようにした。
Config::ENVの場合、paramではなくlocalを使えやって話なのだけど、ついうっかりやってしまいがちだし、paramで上書きしてもエラーもでないのでやめた。
ただちょっとここはブレそうです…。
11. サンプルアプリのテスト追加
サンプルアプリのテストは書いていなかったのだけど、動いてるか確認するが一々めんどかったのでテストを書いた。
Malts::Style::Premium
1. Controllerのdbメソッド削除
Controllerの中でdbを触らせたくなかった。それでどうしよう…って考えてたんだけど、普通にControllerの中にdbメソッドなければええやんってなったのでそうした。
コードもすっきり。
2. Scope::Container::DBIを使い始めた。
modelではdbメソッドがあったけど、dbメソッドを削除してdbhメソッドを新たに作った。
例えばTengを使いたい場合は、Malts::Style::Premium::ModelをMyApp::Modelとかに継承して適当にdbメソッドを作る感じでいいかなと思う。
DBIをそのまま使いたいならdbhであれしたらおｋ
しかも、Amon2::DBIとかDBIx::Handlerとかも設定で渡したら多分使えるので便利。
eg/MyTest以下にテストでも使ってるサンプルアプリがある。
あと、$self->{db}とかで自分で持つよりScope::Containerを使うと他のモデルで使いまわせるのでよいと思われる。
Teng::Schema::Loaderとか開発の時は便利だし使いたいとか結構変える事が多いと思うので、dbメソッドは自分で書いた方がいいと思う。
今までのやり方は継承して、設定変えてとかしなきゃいけなくて、クソめんどくさかったし、これでいいわってなった。またコードもすっきりして見やすくなった。
まとめ
コードのテスト・ドキュメントは修正したけど、Githubのドキュメントを書きなおしていない。つらい。
hisaichi5518がPerlを書いて、つついて、イチャイチャするブログ。最近はnode.jsもやってる。
最近の記事
最近のコメント
リンク
ページ
カテゴリ
アーカイブ
タグ一覧