Rapid Website Development with CGI::Application

by Mark Stosberg
October 19, 2006

This article provides an update on the popular and mature CGI::Application framework for web applications. It assumes a basic understanding of the system, so reviewing the previous Perl.com article about CGI::Application may be helpful background reading.

CGI::Application and Catalyst Compared

You may recall the Perl.com article on another MVC web framework, Catalyst. First, I want to clear up possible confusion by explaining how the CGI::Application and Catalyst relate.

With the many plugins available for CGI::Application and Catalyst, both frameworks offer many of the same features.

Both provide convenient methods to access many of the same underlying modules including Data::FormValidator, HTML::FillInForm and templating systems such as Template Toolkit and HTML::Template.

Both frameworks work in CGI and mod_perl environments, although CGI::Application loads faster in CGI. Each one provides unique features to help with development and debugging. Catalyst includes a built-in web server for easy offline testing and development. CGI::Application provides a persistent development pop-up window that provides convenient reports on HTML validation, application performance, and more.

While CGI::Application and Catalyst share many of the same strengths, they also face the same challenge of attracting users and developers.

As the expectations for web site features and quality increase, the toolkit that a web developer depends on must increase and expand as well. The more plugins that are compatible with our framework, the easier our job is. We each have a selfish incentive to attract others to use the same framework. Users become contributors, and contributors write plugins to make our lives easier.

CGI::Application and Catalyst already share users and developers of many of the Perl modules they depend on. With PHP and Ruby on Rails both on the rise as web development solutions, those who prefer Perl have an incentive to promote the best the language has to offer.

What A Difference Half A Decade Makes

CGI::Application development took off around the 4.0 release for two reasons. To start with, it formalized a plugin system, which led to the release of some initial plugins. Next, the 4.0 release added a callback system, allowing the plugin authors to automatically add actions that take place at particular points in the request cycle.

For example, the AutoRunmode plugin registers itself at the "prerun" phase, allowing it to adjust which run mode is selected. Another plugin might register to add a cleanup action in the "teardown" phase.

The combined result was a boom in plugin development. While the core of CGI::Application has remained small and stable, there are over three dozen plugins now on the CPAN.

Here's a tour of some of the enhancements that have come about as a result of the new plugin and callback system.

Simplified Runmode Syntax

The built-in way to register a run mode typically involves calling run_modes() within setup():

sub setup {
   my $self = shift;
   $self->run_modes([qw/
        my_run_mode
   /]);
}

# later...
sub my_run_mode {
 ...
}

With the AutoRunmode plugin, it's now very easy to declare that a method is a "run mode" handling a CGI request rather than an internal function. The syntax is simply:

    sub my_run_mode : Runmode {
        my $self = shift;
        # ...    
    }

You can still use setup(), but it's no longer necessary.

Pages: 1, 2, 3, 4

Next Page