ドキュメントのこさないとほんとこまるので、ここにも書く。 Module::Setup::Devel とは module-setup コマンドから flavor を開発する為に用意された機能がまとまっている。 flavorのディレクトリ構成の作成、テスト、pack化までを一元で行う。 create flavor module-setup --devel FlavorName で、 FlavorName という flavor を作る事ができる。 cd FlavorName して、ディレクトリ移動して、flavorの作成を行う。 test flavor flavor のディレクトリの root にて module-setup --devel --test とすると、 t/all.t を自動的に作って、意図した flavor が作れてるかテスト出来る。 テストを行うには config.yaml を
追記 この記事は Any::Moose 0.02 以前が対象です。 0.03および、現在の最新版 0.04 では MouseとMooseを挟んだ処理の挙動が以下のように変わってます。 $VAR1 = bless( { 'roles' => [], 'superclasses' => [ 'Mouse::Object' ], 'name' => 'ANY', 'attributes' => {} }, 'Mouse::Meta::Class' ); $VAR1 = bless( { 'roles' => [], 'superclasses' => [ 'Mouse::Object' ], 'name' => 'ANY2', 'attributes' => {} }, 'Mouse::Meta::Class' ); ようするに最初にuse Any::Mooseをした時にMooseがloadされ
短期間でCPANに上がってる名が通ったO/Rマッパ+αを目を通して、ORMマッパの必要最低限なコンポーネントを整理した。ぶっちゃけもっと削っても良いが一般的にするためにもリストアップ。 ORM 基幹的なクラスで使い方はORMによりけりで、特に無くても良い。 ORM::Schema テーブル定義を行う場所。物によってはデータベースの定義だけ行って。テーブルの定義はORM::Table的な物で行う。 どっちにしろテーブルの定義には変わらない。 大ざっぱに言うと、このクラスからselect系のメソッドが生えている。 ORM::Iterator 結果の行を取り扱うイテレータ。 DBICならDBIx::Class::CursorになりMoCoならDBIx::MoCo::Listが担当。 ORM::Row 結果の行ごとのオブジェクト。だいたいはORM::Schema or Table で定義してるco
空前のMooseブームが到来してるのでCookbook読んで理解したことを書いた。 Roleについてはdannさんが書いてるので割愛。 http://catalyst.g.hatena.ne.jp/dann/20080501/p1 Moose っつうのは高機能なAccessorが作れる以外にも、親クラスのメソッドの前後に色々hookできたりとか、中にhookしたりとか、java的なinterface定義できたりとかできるよ。 OOPらしいOOPをPerlで実現させるって言われてるけど、Perl的に言うと上の一文じゃないのかな。 他にも何ができるか見てる最中。 今日はMooseネタしか書かないから http://d.hatena.ne.jp/yappo/20080501 をブクマするといいよ。
今空前のCatalyst MVCブームなのでSledgeを劣化させたSoozyにCatalystの実装を書いた身として書いとく。 ModelにDBICをそのまま使っちゃってる時点で何だかモデルじゃないし、何でかControllerにロジックが入ったりとか、酷い時にはViewであるTTのtemplate fileにロジックが入ってしまったりとか酷い事になっている今日この頃。(それはSoozyとしての設計ミスっぽい所もあるけども) 有る意味Catalyst本体がControllerであって、CatalystのControllerであるというみかたもできるとかどっかで言ってた記憶もあるなと。 ちょっと微妙に違うか。 CatalystはControllerでCatalystのController(MyApp::Controller)は、それを拡張する為のプラグインのような物か。 miyagawaさ
load_componentsはモジュール作成者がいじる load_pluginsはモジュール利用者がいじる という住み分けがいいと思う。 Soozy Con#3の懇談会でClass::C3 Vs Class::Trigger的な話が盛り上がっていたけれど Class::C3が何故DISられるかってのは、読み込み順を考えて$self->next::methodしないと混乱するから。 継承順をどうするかは、モジュールを作る側が責任をもって考えて、ユーザはpluginを追加するだけという状態にすると混乱しなくてすむ。
さいしょは#catalyst-jaに空気読まずにやってたけど #coderepos@freenode になりますんた。 plaggerbotのようにcodereposbotいれます
http://coderepos.org/share/ いちおう作ったお! commit権いる人はhtpasswdのデータ送ってくだしあ。 見逃さなければついかするます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く