CGI Application Modules for CPAN

Note that the param() method offered by CGI::Application is different from the 

param() method offered by CGI.pm objects. CGI::Application's param() accesses 

configuration data from the instance script, whereas CGI.pm's param() accesses 

incoming CGI parameters. Be careful not to confuse the two you don't want to 

start opening arbitrary files on your file system based on CGI input!

By making your applications configurable through their instance scripts, 

you'll increase your opportunities for application reuse. As I'll show you next, 

building a CGI::Application module for CPAN requires you to focus on config 

urability as a primary goal.

CGI::Application and CPAN

Now that you know how to build reusable applications using CGI::Application, 

you're ready to learn to release your creations on CPAN. But first, I should address 

a burning question that's likely on your mind why release CGI applications on 

CPAN? To me the answer is simple: because it will help reduce the needless work 

that Perl CGI programmers do every day. The Web is filled with endless incarna 

tions of the same applications done and redone bulletin boards, Web counters, 

shopping carts, and so on. Each one needs to be done again and again primarily 

because they need to look or function slightly differently.

Since most CGIs include their HTML inline with their code, either by including it 

in the source or including the source in the HTML (that is, HTML::Mason or 

EmbPerl), it is unusual to be able to reuse applications across projects. Furthermore, 

since most CGIs are built as scripts, the only way to reuse them is to copy them 

from project to project. With CGI::Application comes the opportunity for the Perl 

community to pool its collective strength and create powerful, configurable, 

reusable Web applications. And after all, isn't reusability what CPAN is all about?

Okay, enough manifesto, let's get down to the mechanics.

Size and Shape

A good CGI::Application module has to be the right size and shape; otherwise, it 

won't fit into the large variety of Web sites on the Internet. What I mean is that an 

ideal module should be sized to serve a clear and defined purpose within the 

larger scheme of a site. And it should be shaped to fill several screens without 

requiring a great deal of overlap with the rest of the site. For example, the BBS 

application discussed earlier would make a good CPAN module (if it actually 

worked and had a better name like, say, CGI::Application::BBS). It is clearly a sep 

arate application within a larger site that can safely control its own screens.

26

269

9