unknownplace.org

出社。

退社。

GJ!

さっそく Cred::Hatena を作ってみた。

ここにも導入しようかな。

が見えなくなっちゃってる。ここにミラーされていた XHTML リファレンスに依存しまくっていたので困りまくる。

とりあえず webarchive.org でみれた。

XHTML リファレンス [WEB ARCHIVES REPRINT]

と思いきやアーカイブされてないページもあるなぁ。

今までのルートコントローラは MyApp.pm 自体だった。

でもこれだと YAPC でちょろっと話したように Catalyst は自分自身も Plugin も MyApp の親としてロードされるようになっているため、ルートコントローラと Catalyst 自身やプラグインの名前空間が干渉する。

いわゆる sub login 問題ですが、普通に prepare とかいうアクション定義すると Catalyst の prepare 呼ばれなくなってアボンとかいうことになってて、かなり微妙な感じだった。

なので 5.66 から MyApp::Controller::Root に外付けできるようになった。一応まえと同じ書き方でも動くけど、Root.pm 推奨という流れ。

とか書いておいてみる。

いつの話題だよｗ

1章終わったー。

退社。

昨日寝る前に20分くらいやった。

おもろそうな予感がした。

現在 Catalyst::Plugin::RPC という RPC の統合プラグインを作成してます。

以下のような感じ。

use Catalyst qw/
    RPC
    RPC::Serializer::URIQuery
    RPC::Serializer::XML
    RPC::Serializer::JSON
    /;

などと RPC と一緒に使いたいプロトコルのシリアライザをロードしておくと

# endpoint
sub rpc : Global {
    my ( $self, $c ) = @_;
    $c->rpc;
}

sub echo : RPC('myapp.echo') {
    my ( $self, $c, @args ) = @_;

    @args;
}

というような RPC アクションが利用できるようになるというものです。

deserializer はリクエストの Content-Type から自動的に判別されるため、同じアクションを複数のプロトコルで共有できます。(このあたりはmiyagawaさんインスパイア)

serializer はデフォルトでは deserializer と同じになりますが、format=json などとクエリで渡し指定することも可能となっています。

Plugin::Flavour と組み合わせて /rpc.js 等とアクセスすれば Serializer::JSON が使われるようにもできますかね。これはどうしようかな。

とりあえず今はRPCプラグイン本体を大まかに実装して、sri のコードコピペして Serializer::XML 作って XMLRPC のみ動くようになった段階。

なんか同じようなことしてる人がいるっぽいので情報共有もかねて書いてみるｗ

フィードバックフィードバック！