Delegationを使わないでNon-Mooseクラスを継承 - とほほのN88-BASIC日記
FAQにもあるけど、Moose::Objectも継承して->meta->new_objectを明示的に呼ぶことにより、delegationを使わないでNon-Mooseクラスを継承することもできる。 use strict; use warnings; { package Parent; sub new { my ($class, %args) = @_; bless {name => $args{name}}, $class; } } { package Child; use Moose; extends qw(Parent Moose::Object); no Moose; sub new { my $class = shift; my $obj = $class->SUPER::new(@_); return $class->meta->new_object( __INSTANCE__
モダンなCatalystコンポーネントを書くときは - とほほのN88-BASIC日記
Catalystがモダンかどうかは置いておいてCatalystのコンポーネントを書く時のお作法として 大昔は ... use base qw(Catalyst::Action); use NEXT; sub execute { my $self = shift; $self->NEXT::execute( @_ ); ... ちょっと前は ... use base qw(Catalyst::Action); use Class::C3; sub execute { my $self = shift; $self->next::method( @_ ); ... モダンなのは ... use base qw(Catalyst::Action); use MRO::Compat; sub execute { my $self = shift; $self->next::method( @_ )
mod_perliteを試してみた - とほほのN88-BASIC日記
Ideas - O'Reilly Media modperlite PHPのようにファイルを置くだけで実行されてCGIより速くてmod_perlより簡単なapache moduleだそうです。去年からのCGI frameworkブームを補完する上でも試してみるっきゃないということで まずはソースの取得 svn co http://code.sixapart.com/svn/mod_perlite/trunk modperlite cd modperliteちなみにもうすぐgithubに移行されるようです。 コンパイルとインストールはapxsにパスを通して ./Build.PL ./Build ./Build installhttpd.confとかconf.d/modperlite.confとかに LoadModule perlite_module modules/mod_perlite.s
Perlの軽量ウェブアプリケーションフレームワーク最新事情 - とほほのN88-BASIC日記
前代未聞のPerl軽量ウェブアプリケーションフレームワーク祭りの中、いかがお過ごしでしょうか？ 紆余曲折があってこんなことを言ってたわりに何もしてないでぼーっとしている間に、腕に覚えのある兵達が我も我もと手を動かしてくれたので、申し訳なさ半分で懲りずにベンチマークを取ってみました。 http://d.hatena.ne.jp/tokuhirom/20081111/1226418572 NanoA というウェブアプリケーションフレームワークをかいてみた - kazuhoのメモ置き場 YappoLogs: Yacafi という軽量CGIフレームワーク書いたよ みんな基本的に軽量なフレームワークをうたっていて、開発効率よりも軽さや配布のしやすさを売りとしているので特に問題ないと思います。 比べたのは上の3つと モジュールを使わないcgi CGI.pmでヘッダ出力をするもの 軽量フレームワークの代
Mojoについて思う - とほほのN88-BASIC日記
Mojoを使ってみた - Charsbar::Noteを読んで、興味が沸いた。 今の会社も結構レガシーな仕組みを使ってるわけで、新しく一からサーバーを立てるようなサービスじゃないと、なかなかCatalystとか使わせてもらえないわけです。そんな場合、どうするかというと素のCGIかせいぜいCGI::Applicationを使う羽目になるわけです。受託開発でもよく聞くケースですね。 なので 国内では同じような趣旨のHTTP::Engineが開発されていますが、Mooseをバリバリ使っているHTTP::Engineに比べて、Mojoはアクセサからなにから、ほとんどのコードを自分で再実装しているので、インストールに困るような依存モジュールは（ほとんど）なし。ぶっちゃけ「さくらのレンタルサーバ」にまるっとFTPアップロードしてやればそのまま動きますし、Windows上でも（ふつうに使う分には）問題な
Module::Setup::Flavor::CatalystStarterとしてコミットした - とほほのN88-BASIC日記
下のやつをModule::Setup::Flavor::CatalystStarterとしてcodereposにコミットしました。 module-setup --init --flavor-class=CatalystStarter catalystすると~/.module-setup/flavors/catalystにflavorがインストールされます。 module-setup MyApp catalystとすればcatalyst.pl MyAppと同じことをしてくれます。 で、これの何がうれしいかというと、~/.module-setup/flavors/catalyst/以下をいじくればオレオレcatstarterが作れるってことです。 ディレクトリ構造がそのままなので視覚的にいじれるのでわかりやすい。 で、保存しておきたくなったら module-setup --pack MyCat
最近使ってるCatalystなアプリケーションのディレクトリ構成 - とほほのN88-BASIC日記
最近はもっぱらこんな構成 MyApp/ |-- Changes |-- Makefile.PL |-- README |-- conf - 設定ファイルはまとめてここへ | `-- myapp.conf |-- docs - ドキュメントとかSQLとか |-- lib | |-- MyApp | | |-- Base - Base::Controllerとか基底クラス | | |-- Component - ビジネスロジッククラス | | |-- Controller | | |-- Model | | |-- Plugin - オレオレプラグイン | | |-- Schema - DBICのスキーマ | | `-- View | `-- MyApp.pm |-- root | |-- db - SQLiteを使うときはこの辺 | |-- static | | |-- scripts -
Data::ObjectDriverでトランザクション - とほほのN88-BASIC日記
CPANに上がってるのだとどーやったらいいのかさっぱりわかんなかったけど、code.sixapart.comに上がってるやつだとこんな感じでやるみたい。 Data::ObjectDriver::BaseObject->begin_work; eval { my $album = Album->new; $album->title('Album'); $album->artist('Artist'); $album->save; for ( 1 .. 5 ) { my $track = Track->new; $track->title("Track $_"); $track->artist("Artist $_"); $track->album_id($album->id); $track->save; } }; if ($@) { Data::ObjectDriver::BaseObje
最近のCatalystのプラグインのロードの仕方 - とほほのN88-BASIC日記
昔のCatalystのプラグインのロードは全て use Catalyst qw/-Debug ConfigLoader Static::Simple/; ってなってたんだけど、最近ディストリビューションでは __PACKAGE__->setup( qw/-Debug ConfigLoader Static::Simple/ ); ってなってる。 コミュニティに学ぶってことで指針を聞いてみた。 16:48 (hidek) i have question about loading plugin into catalyst 16:48 (hidek) which is better use Catalyst qw/Plugin/ or __PACKAGE__->setup(qw/Plugin/) ? 16:51 *ferz join #catalyst@perl (~fer@79.0.206.
Catalystのデフォルトのconfigフォーマットが変わった - とほほのN88-BASIC日記
[Catalyst] IMPORTANT: To all Catalyst::Whatever Authors, please read and ACT YAML is not an appropriate configuration format for use in perldoc because both yaml and perldoc are sensitive to white space. Therefore they interact. Even worse they interact in different ways depending on the formatter being used. CatalystのコンポーネントやプラグインのPODにはYAMLの設定例を書かない方がいいよとのこと。PODとYAMLともにwhitespace sensitiveってのが理由。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
