CGI::App: A Generic Base Controller

markjugg on 2006-11-29T01:52:41

This is in response to LTJake's examples of setting up a generic base controller with Catalyst

Here's what the same thing would look like using CGI::Application.

# Normally one CGI::App dispatch table is used for
# an entire application, not just one module. 
use CGI::Application::Dispatch;
CGI::Application::Dispatch->dispatch( 
prefix  => 'MyApp::Controller::Admin::Account',
    table => [
        'admin/account/:id/:rm'  => {},
        'admin/account/:rm'      => {},
        ''                       => {},
    ]

);

package MyApp::Controller::Admin::Account;
use base 'CGI::Application';
use CGI::Application::Plugin::AutoRunmode;

use strict;
use warnings;

# default  for /admin/account/
sub list     : StartRunmode { die "index of accounts" }

# methods on /admin/account/$rm
sub create   : Runmode { die "create an account" }

# methods on /admin/account/$id/[$rm]
sub instance : Runmode { # do something with $self->param('id') }
sub view     : Runmode { die "view account" }
sub update   : Runmode { die "update account" }
1;

The amount of code needed in both cases is comparable, but there are two important philosophical differences here:

1. Small components CGI::App encourages small apps that play well together. Here you see that the dispatcher and 'AutoRunmode' extensions get pulled in. Don't need 'em? They don't get loaded. Catalyst has a more monolithic approach, which I believe consumes more memory in a default setup.
2. Global dispatching allows you to see and adjust the URI to runmode mappings at a bird's eye level, making adjustments across the application in one place. With Catalyst, dispatching logic is stored with each run mode, tying each run mode to one kind of dispatching, and making it difficult to see the big picture of all the mappings defined.