MooseX::DOM - D-6 [相変わらず根無し]
MooseX::DOM MooseX::DOMってのを作りました。オブジェクトの裏にXMLで定義されたデータが存在していて、それに対して操作するために使う物です。DBIx::ClassとかがObject Relational Mapperなら、これはObject XML MapperでOXMですね。 ともあれ。これを使うと在る程度単純なXMLに関しては簡単にaccessorとかを定義することができます。こんなXMLを操作するためのオブジェクトを作りたいと仮定します： <foo> <bar>適当な文言</bar> <baz>ほげほげ</baz> </foo> その場合、こんな感じで定義すると package Foo; use Moose; use MooseX::DOM; has_dom_root 'foo'; has_dom_child 'bar'; has_dom_child 'baz'
Apache::Test事始め - D-6 [相変わらず根無し]
Apache::Test事始め 年末前後からApache::Testで真面目にテストを書き始めている。 ところが全くドキュメントがないんだね。いや、あるんだけど、携帯の機能を使いたいだけなのにあの厚いマニュアル読むの？みたいな感じで。まぁというわけでとにかくざくざくっとドキュメント読んでテスト書いてたらようやくなんとなく分かってきた。この間ある程度他人にも説明できたので自信ついたしw Apache::Testはmod_perlハンドラをテストするときに使う。ディストリビューション等でmod_perlをテストしようと思うとApache自体を立ち上げたりなんだりしなければいけなくて「一体どうテストすればいいんじゃ？！」となりがちだが、Apache::Testを使うと、テスト用httpd.confの生成テスト用のapacheの起動／停止mod_perlハンドラ上で動かしたTest::More等の
ＭＶＣのモデルはDBじゃなくてもいいんだよ - D-6 [相変わらず根無し]
ＭＶＣのモデルはDBじゃなくてもいいんだよ id:charsbarさんが、先ほど書いたエントリに関して 後半その通りなわけですが、CatalystはModel::DBIC系のせいでMVCが誤解されてるのよねー と言っておられる。たしかにその通り。「モデルってDBでしょ？」みたいな印象が一般的にあると思う。 そういう印象を持ってる人に説明すると、「モデルを作る」って何かというと、DBのようなストレージにあるものをどうこうする、ではなくて「データに対する操作を抽象化したものを作る」ということです。例えば、ブログを作ると、Blog、BlogEntry、BlogUserみたいなモデルを作ります。そしてその操作方法はこんな感じ： # ブログを登録するみたいなAPI MyApp::Model::Blog->create({ user => $blog_user, title => $title, .
Catalyst::Model::AdaptorがGJ - D-6 [相変わらず根無し]
Catalyst::Model::AdaptorがGJ Catalyst::Model::Adaptorがリリースされていたので早速使ってみた。 それまでもなるたけ全てのロジックをモデルにいれようとしてたんだけど、モデル自体がCatalystにべったりで嫌な感じだったのでどうやって分けようかと考えてきた。例えばCatalystに載せたくない（メモリを食う割に、別に非同期でバッチ処理すればいいものとか）もmodelにしか生き場所がないのにCatalystから分離できないという妙な状態だったりした。 そこでCatalyst::Model::Adaptorです。Minicoの現在の開発版ツリーはそんなところからAdaptorで実装をリファクタリングしてみた。 多分ケースバイケースなんだろうけど、俺の場合は以下の数点を考慮しながらやったらいい感じになってきましたよ： Minico::Busines
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
