Future Post: Compare and Contrast CGIApp and Catalyst

Author: fREW Schmidt

5 Jun

So I’d like to do a post on CGIApp and Catalyst. People on IRC keep telling me that using CGIApp is wrong (mostly because they’ve never used it) and that I should switch to Catalyst.

Catalyst may be great, but I haven’t seen any solid posts about how Catalyst is great. So help me out. Ignoring the fact that Catalyst is what everyone uses (so there are lots of plugins for it) what makes it so good?

Filed under: Uncategorized

3 Responses for "Future Post: Compare and Contrast CGIApp and Catalyst"

Tomas Doran June 5th, 2009 at 5:02 pm 1
The main thing which has always attracted me to Catalyst is the flexibility of the ways in which you can arrange paths in your application, and the fact that path definitions are intrinsic to your controllers, rather than having an external ‘route map’ of some form.

With Catalyst 5.8 and Moose, this has got undescribeably powerfull (although I’m trying to work up to showing some really cool use cases in my blog).

As a simple case, if you have a CRUD system, then attaching standard view/edit/delete uris (and associated processing) should be as simple as:

with qw/MyApp::IsViewable MyApp::IsEditable MyApp::IsDeleteable/;

sub item : Chained(‘/’) PathPart(‘thing’) CaptureArgs(1) {
my ($self, $c, $id) = @_;
$c->stash->{item} = $c->model(‘Db::Thing’)->find($id);
}

and this gives you:
/thing/ (GET to view)
/thing/ (POST to edit)
/thing//delete (POST for web)

You can add extra custom actions to the URI space of ‘thing’ just by including them in the code above – but the basic elements of your web interface are really really to write once, and then just reuse..
Matt S Trout June 6th, 2009 at 9:40 am 2
Mostly, that any sufficiently large CGI::App codebase appears to contain an ad hoc, informally-specified, bug-ridden implementation of half of Catalyst.

Having a solid HTTP abstraction with IOC capabilities and a standard component API is important – and CGI::App’s plugin system is a lot more limited than the many places you can override, tweak and extend Catalyst.

Catalyst doesn’t just have lots of extensions because everybody uses it – it got many of those users because there were plenty of clean ways to make those extensions in order to build your application base up towards the problem in a maintainable fashion.

The way I see it, CGI::App is (intentionally) a microframework; Catalyst is more a metaframework. So for an application of … half a dozen pages? CGI::App may be the best choice to minimise the amount of code loaded, but for a larger app you usually end up taking advantage of enough of the features of Catalyst to make it worth starting there.
Compare and Contrast CGIApp and Catalyst | A Foolish Manifesto June 11th, 2009 at 9:03 pm 3
[...] may remember my post from before asking about the differences between these two frameworks. I only got a couple of responses, but [...]