NOTE: This article was written in 2005. For more up-to-date information on deplyoment, please see http://dev.catalyst.perl.org/wiki/deployment As a companion to Day 7's mod_perl article, today's article is about production FastCGI deployment. [Content migrated to Deployment in Catalyst::Manual::Cookbook]

Adding RSS feeds to your stuff in Catalyst is really simple. I'll show two different aproaches here, but the basic premise is that you forward to the normal view action first to get the objects, then handle the output differently This is the aproach we chose in Agave (http://dev.rawmode.org/). sub rss : Local { my ($self,$c) = @_; $c->forward('view'); $c->stash->{template}='rss.tt'; } Then you nee

NOTE: This article was written in 2005. For more up-to-date information on deplyoment, please see http://dev.catalyst.perl.org/wiki/deployment In today's entry, I'll be talking about deploying an application in production using Apache and mod_perl. mod_perl is the best solution for many applications, but I'll list some pros and cons so you can decide for yourself. The other production deployment o

DRY is a central principle in Catalyst, yet there is one piece of code that is identical in 90% of all Catalyst applications. sub end : Private { my ($self,$c) = @_; return 1 if $c->res->body; return 1 if $c->response->status =~ /^3\d\d$/; $c->forward( 'MyApp::View::TT' ); } Basically, we want to render a template unless we already have a response, or are redirecting. So, rather than doing this ag

NOTE: This article was written in 2005. In the meantime, Catalyst has switched to using Config::General as the format for its configuration files. YAML files being whitespace-sensitive, copy/pasting from POD often caused problems. See also the Catalyst Wiki (http://dev.catalyst.perl.org/wiki). When you start a new Catalyst app you configure it directly with __PACKAGE__->config, thats ok for develo

NOTE: This article was written in 2005. Make sure to check the Catalyst Wiki (http://dev.catalyst.perl.org/wiki) for updated information. So, you want to put your Catalyst app out there for the whole world to see, but you don't want to break the bank. There is an answer - if you can get shared hosting with FastCGI and a shell, you can install your Catalyst app. First, run perl -MCPAN -e shell and

NOTE: This article was written in 2005. Make sure to check the Catalyst Wiki (http://dev.catalyst.perl.org/wiki) for updated information. Catalyst makes it easy to employ several different types of caching to speed up your applications. There are three wrapper plugins around common CPAN cache modules: Cache::FastMmap, Cache::FileCache, and Cache::Memcached. These can be used to cache the result of

NOTE: This article was written in 2005. Make sure to check the Catalyst Wiki (http://dev.catalyst.perl.org/wiki) for updated information. This is actually one of the features we brought over from Maypole. There it was called Maypole::Plugin::Component. Basically, the idea is to set up new request/response objects, and do an internal request, then return the output. It's quite handy for various sit

NOTE: This article was written in 2005. Make sure to check the Catalyst Wiki (http://dev.catalyst.perl.org/wiki) for updated information. This text will show you how to start using DBIx::Class as your model within Catalyst. Let's assume, we have a relational set of tables: shell> sqlite3 myapp.db SQLite version 3.2.1 Enter ".help" for instructions sqlite> CREATE TABLE person ( ...> id INTEGER PRIM

When you have your users identified, you will want to somehow remember that fact, to save them from having to identify themselves for every single page. One way to do this is to send the username and password parameters in every single page, but that's ugly, and won't work for static pages. Sessions are a method of saving data related to some transaction, and giving the whole collection a single I

NOTE: This article is now obsolete. Please refer to http://dev.catalyst.perl.org/wiki/gettingstarted/howtos/interim_authorization_and_authentication_example. This is done in several steps: Verification Getting the user to identify themselves, by giving you some piece of information known only to you and the user. Then you can assume that the user is who they say they are. This is called credential

メモ＆カレンダーWebアプリケーションつくりました。 Tagがつけられるメモ帳Webアプリケーションをつくってみました。次のキラーアプリらしいカレンダー機能もついています。 http://femo.nomadscafe.jp/ ↓Helpで使っているスクリーンショット メモのTagとして、2005-12-09と日付をいれるとカレンダーの方に整頓される仕組みです。カレンダーでもTagCloud風にメモ件数の多い日は字が大きく表示されます。 Catalyst + Ajax + TypeKey認証 + Tagging + はてな記法と話題の技術を使い派手に実装しました。TypeKeyのアカウントを持っていればログインだけで使えるのでぜひお試しください。ご意見もくださいませ。

NOTE: This article was written in 2005. For more up-to-date information on deplyoment, please see http://dev.catalyst.perl.org/wiki/deployment You know the problem, you got a application perfectly running on your development box, but then *shudder* you have to quickly move it to another one for demonstration/deployment/testing... PAR packages can save you from a lot of trouble here. They are usual

CatalystのStatic::SimpleとSessionの相性が悪い CatalystのCatalyst::Plugin::Static::SimpleとCatalyst::Plugin::Session(::State::Cookie)の相性が悪い。最悪の場合セッションキーが消されてしまう。 原因はprepare_actionの実行順で、解決策としてはプラグインのロードの順番なのだが、 use Catalyst qw/Static::Simple　Session/ とした場合、 prepare_actionはStatic::Simpleの方が先に実行される。ところがStatic::Simpleのprepare_actionは、 return $c->NEXT::ACTUAL::prepare_action(@_); で終わるため、Sessionではなく、SUPER:: prepar

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