「モダンPerl入門」の入門株式会社ガイアックスでは、若手メンバーが多いながらも、新しい技術を取り入れたプロダクト作りに取り組んでおります。 今回は、Catalyst5.8や、CatalystのAPI化といったトピックを、プロダクトとして実装したときに出てきた問題点とその解決策についてお話しします。 Read less
JPA セミナー #1 (Session 2 Catalyst 改) - Craftworks Tech Blog - Branch
1. Plugin プラグインの使用を控える 間違った使用方法、実装方法で定義されていることが多い プラグインの使いどころ リクエストディスパッチのロジックを監視、変更する場合のみ リクエストパラメーターの変換、Catalyst のメソッド実行チェーンの変更を含む 本当に使わない方向で Catalyst::Plugin::* の中にはそもそもプラグインとして実装されるべきでないものが多い コンテキストオブジェクト ($c) にメソッドを追加する実装がそもそも良くない手法 大半のプラグインはモデルとして実装されるべき それ以外はそもそも存在するべきがどうかさえ疑問 (eg.Catalyst::Plugin::Message) Catalyst::Plugin::Authentication はどうなの？ とはいえ、例外はある 認証系とセッション系はプラグインで存在しなければならない意味がある
Catalyst/DBICでDigest認証する - 日向夏特殊応援部隊
自分の為のメモですよ。 準備 まずはCatalystプロジェクトを作ります $ mkdir -p /path/to/dir $ cd /path/to/dir $ catalyst.pl AuthSample ユーザー用のDBICスキーマを定義します。 $ module-starter --module AuthSample::Schema $ cd AuthSample-Schemaでこのディレクトリにて、 CREATE TABLE user ( user_seq INTEGER PRIMARY KEY, user_id TEXT UNIQUE, password TEXT, created_on DATETIME, updated_on DATETIME ); こんなスキーマを定義して、schema.sqlとして保存して、 $ sqlite3 -init schema.sql auth
Catalyst::Manual::Cookbook - Catalystクックブック
題名 Catalyst::Manual::Cookbook - Catalystでお料理を 説明 ママが昔よく焼いてくれたおいしいコード！ レシピ デバッグ画面を強制表示する endアクションでdie()を呼び出すと、リクエストの最後にデバッグ画面を強制表示させることができます。 sub end : Private { my ( $self, $c ) = @_; die "forced debug"; } いちいちこれを書いたり消したりするのが面倒なら、endアクションにこんな条件文を加えることもできます。 sub end : Private { my ( $self, $c ) = @_; die "forced debug" if $c->req->params->{dump_info}; } こうしておくと、たとえばクエリストリングに"&du
Catalystで携帯対応セッション - pepponの日記
はじめてやってみた。 普段は qw/Session Session::Store::FastMmap Session::State::Cookie/のコンボだったんだけど qw/Session Session::Store::FastMmap Session::State::URI/にしてみて携帯対応にしてみた。 携帯なんかだとクッキーつかえないっていうんで、URLにセッションIDを付加する。 configには下記のように session => { param => 'sid', verify_address => 'true', },これでURLの最後に?sidでセッションIDを付加してくれます。 終わり（はやっ） Catalyst::Plugin::Session::State::URI にか以下のように記載されています。 Session Hijacking URI sessions
hide-k.net#blog: Catalyst::Response->redirect()のメモ
Catalyst::Response->redirect()でちょっとはまったのでメモ。 response->redirectの時点でクライアントにredirectレスポンスが帰って処理が終わると勝手に解釈してたためにはまりました。 例えば a : Global { my ( $self, $c ) = @_; $c->res->redirect($c->uri_for('/')); $c->log->debug('after redirect'); #ここも実行される } さらに end : Privateまで呼ばれるため sub end : Private { my ( $self, $c ) = @_; $c->forward( $c->view('TT') ) unless ($c->response->body); } なんてやってたらtemplateが指定されてないよ、と起こ
O/Rマッパ DBIx::Class - end0tknr's kipple - web写経開発
2014/12/20 追記 DBIx::Classのselect等のリファレンスは、次のurlが分かりやすいです http://yanor.net/wiki/?Perl-DBIC O/Rマッパとは、Object-Relational マッパの略称のようですが、今回はperl用orマッパの一つであるDBIx::Classを試してみます。 perl用のorマッパには、Class::DBI もありますが、DBIx::Classは、Class::DBIをインスパイアして作成されたそうです。 また、Class::DBI を CDBI、 DBIx::Class を DBIC と略すそうです。 WEB+DB PRESS Vol.36 の Recent Perl World に記事が記載されていたので、記事に沿って、CLI (コマンドラインインタフェース) の bookmark アプリを作ります。 と書き
Lighttpd-Catalyst Technique
最小設定 lighttpd.conf server.document-root = "/path/to/root" server.port = 80
[O] Catalyst の Model 問題
« Tally's Coffee 渋谷南口店 | トップページ | 渋谷 筏天 ちゃんぽん » Catalyst の Model 問題 [Perl] Catalyst でアプリに依存しない Model は再利用できるようにしたいです。 けれど、標準のヘルパースクリプトだと、 「MyApp::Model::*」以下に作ることになってしまいます。 そうすると、無駄に Model のパッケージ名も長くなるし、 なにより Model が Catalyst に依存することになり、 テストしにくくて死ぬってことで、良いことが無いです。 既存のモジュールを取り込むために、 Catalyst::Model::Adaptor使っても、なんかいまいちな感じ。 ということで、今日このごろの議論を眺めていると、 以下のような方向でまとまりそうです。なるほど。 - はてなブックマーク - タグ
nitsujiの日記 - Catalyst::Manual::Cookbook
Catalyst::Manual::Cookbook - Cooking with Catalyst - metacpan.org Basics Catalystを使う人が知っておいた方がいいこと。 Delivering a Custom Error Page アプリケーションでエラーが発生したときはCatalystは独自のエラーページを表示する。-Debugモードのときはエラーメッセージとコンテキストオブジェクト($c)のData::Dumpの出力を表示する。-Debugモードじゃないときは"Please come back later"が表示される。 エラーページを変更するにはendメソッドにエラー処理を書けばいい。例を示す。 sub end : Private { my ( $self, $c ) = @_; if ( scalar @{ $c->error } ) { $c->st
たけまる / catalyst
_ AtomPub - Catalyst::Controller::Atompub v0.5.0 [atompub][catalyst] zigorou さんからアドバイスをもらいつつ，Makefile.PL も直してもらい つつ，コレクション URI の変更方法を修正しました．いままでは，コレク ション URI を変更すると EditURI やサービス文書がおかしくなることが あったのですが，完全に直っていると思います． http://svn.coderepos.org/share/lang/perl/Catalyst-Controller-Atompub/trunk # Atompub の export が多いのは，今さら変更できないということで見逃 # してください ＞＜ 一ヶ月近く前に，daiba さんから "URI がおかしい" という報告をもらっ ていたのですが，わりと面倒な修
Catalyst::Manual::Cookbook::Test - libnitsuji.so
さらに分割。 テストについては外部からリクエストを送って、みたいな方法しかない？ようなので、内部のモジュール、特にモデル部分のテストをどうやってやるかが問題。 そこは普通のPerlモジュールと同じ方法でできるのかね。 http://search.cpan.org/~jrockway/Catalyst-Manual-5.700701/lib/Catalyst/Manual/Cookbook.pod#Testing テストはWebアプリケーションの開発プロセスに不可欠な要素だ。テストは複数人での開発とコードの変更を容易にする。 Testing Catalystは開発中のテストと本番環境にデプロイする前のテストをやりやすくする。 Catalyst::Testは同じテストをローカル（外部のデーモンを除く）とリモートのHTTPサーバに対して行えるようにする。 Tests スケルトンアプリケーションの
lighttpd で FastCGI / CGI-Application-FastCGI-0.01 - naoyaのはてなダイアリー:
Catalyst の雛形アプリ (catalyst.pl MyApp 叩くと出る Hello World! 的なやつ) をいろんなとこで動かしてベンチとってみた。 typester さんによる Catalyst を使ったベンチマーク。Catalyst そのもののベンチマークよりも lighttpd の速さに注目。ずいぶんと速いです。 はてなでも画像サーバーなどの static なコンテンツを返すサーバーに lighttpd を使えないもんかと、ベンチを取ったりしてます。ベンチ結果では、画像ファイルとかだと Apache2 とそこまで差は出ない感じなんですが、単に画像の転送時間が支配的になってるだけかもしれないし、ちょっとトラフィックの多いところに挟んで試してみようかなと思っています。 んで、この typester さんのベンチ結果の中で興味深いのは mod_perl + Apache 1.
blog.nomadscafe.jp: FormValidatorとDBIx::Class::WebFormの組み合わせはいい。
FormValidatorとDBIx::Class::WebFormの組み合わせはいい。 Scaffoldなどではすでに使われているのだけど、FormValidator::Simple(Data::FormValidator)とDBIx::Class::WebForm(Class::DBIの場合はClass::DBI::FromForm)、この組み合わせはヤバいね。非常に楽ができてしまう。 研究中のCatalystアプリの部分だけど、タイトルと、内容、時間(年〜秒まで6つのフォーム)があって、それをDBに入れる場合、 my $result = $c->form( title=>[qw/NOT_BLANK/], text=>[qw/ANY/], {created_on=>[qw/d_year d_month d_day d_hour d_min d_sec/]}=>[qw/NOT_BLANK
Catalystでクエリを扱うための便利メソッド - Unknown::Programming
今までクエリ扱うのにCGI.pmをラップした独自モジュールを使ってたんですが、いくつか便利なメソッドがあったのでそれをCatalystから扱えるようにしてみました。 プラグイン名はとりあえずCatalyst::Plugin::Request::Utilとでも。 package Catalyst::Plugin::Request::Util; use warnings; use strict; use NEXT; use Catalyst::Request; our $VERSION = '0.01'; package Catalyst::Request; sub value { scalar shift->param(shift) } sub value_list { my $self = shift; map { scalar $self->param($_) } @_; } sub e
Catalyst + Lighttpd + FastCGI + DBIC + Schema::Loader に関する備忘録 :: Drk7jp
ここ数ヶ月 Catalyst を触っていなかったらメキメキと記憶から知識が抜けてました・・・orz 恐ろしいことに DBIC もメキメキと忘れてました・・・orz 僕はどちらかというと OR Mapper を使うよりも SQL 直書きしたほうが理解が早い部類の人間なので DBIC つかって distinct とかするコードを書くのが面倒くさくて仕方がない。なので本業の Sledge ベースのアプリは Model 部分に自前の DBI ラッパー使ってコネクションとかも管理してます。 ※ココ時代と逆行してるんでしょうね・・・ とはいえ忘れたままは悔しいので、最近ちょっとしたアプリを作るために Catalyst を使って書いていろいろメモったのを備忘録として残して自分用に公開。ってか DBIC のことなら DBIx::Class::Manual::Cookbook - Miscellaneous
Catalystの基礎 アプリケーション編
Catalystの基礎 アプリケーション編 大西 祥代，廣安 知之，三木 光範 ISDL Report No. 20060913003 2006年 10月 17日 Abstract 本報告ではPerlのWebアプリケーションフレームワークであるCatalystを用いてサンプルプログラムの作成を行う．作成するものは，簡単なbookmarkのアプリケーションである．サンプルプログラムを作成することを通して，MVCモデル型のプログラミングを理解し，Catalystについての理解を深めることを目的とする． 1 はじめに 本報告ではPerlのWebアプリケーションフレームワークであるCatalystを用いてbookmarkアプリケーションを作成する．簡単なサンプルプログラムを作成することでMVC型のプログラミングやCatalystを理解する． 2 準備 2.1 モジュール・プラグ
Perl の MVC フレームワーク Catalyst のお勉強〜その１〜 :: Drk7jp
時間が空いているときに Catalyst のお勉強をしていたのですが、なかなか情報をまとめる時間がとれないのです・・・。思ったより苦戦したので少しずつでもお勉強の情報をまとめていこうと思ってます。今回はその１ってことで。Catalyst をこれからお勉強してみようって方の参考にでもなれば幸いです。 実際には、アプリケーションを１つ作ってみるってところまで既に２週間前に終わっていたりするのですが、その解説に至るまでどれくらい時間かかるんだろう・・・ (｡･ｘ･)ゝ Catalyst の基礎知識 Catalyst のフレームワークの構成は上図のような構成になっています。純粋な MVC ではなく、MV C + A(Apprication) のような構成になっていますが、Application の部分は Dispatcher 機能に相当する部分で、実装時には MVC の考え方で問題ありません。 M
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CP::FormValidator::Simple::Auto の self_rule - Practice of Programming
Perl の MVC フレームワーク Catalyst に入門してみた : NDO::Weblog: