When you use CGI::Application (C:A), you have a small instance script that creates an object (MyApp, for example) which inherits from the C:A base class. The package file that defines MyApp contains "run modes" (methods) that correspond to your web pages.

The problem one may have, is that if your web app grows to be large and complicated (and don't they all?) you may find that your MyApp package contains dozens of methods. All of these have to be read, loaded, compiled, etc. every time, for every page view.

The unwritten assumption in the C:A docs (in my opinion) is that, ideally, you'll be running your app under mod_perl. Because if you use mod_perl, all of your methods get loaded, compiled, etc. when the web server first starts up. It's a one time cost that way. The down side is that it takes a lot more memory, but that's what mod_perl does: it lets you buy faster performance in exchange for larger memory usage.

If you'r stuck running in regular mod_cgi mode, you still have options, but you have to really think about what makes sense for your particular app. Some people break large projects up into multiple smaller projects, each having its own instance script. You can factor out all the common stuff, to avoid redundancy. So you may have objects MyApp1, MyApp2, MyApp3, etc. (each with their own instance scripts), each of which inherit from object CommonStuff, which inherits from C:A. This helps MyApp1 avoid having to load stuff used exclusively by MyApp2, etc. But you can wind up having dozens of little scripts this way, instead of just one big one, which is one thing C:A tries to avoid. C:A:Dispatch can be used in this case, as a instance script "factory" which let's you avoid having multiple, nearly identical instance scripts, but you'll still have lots of package (.pm) files.

Another thing you can do is break out methods into seperate packages, and then "require" them in the methods that need them. This give you a "load on demand" system (rather than loading everything up front with "use").

But if your site is going to be low traffic / low volume, you may not actually see any performance problems using the "one big file / mod_cgi" approach. The problem is that this approach doesn't scale very well as traffic increases into millions of hits per day. But that's a problem most web developers only ever dream of having. Even then, sometimes the easiest solution is buyings a bigger server with more memory. There's no one "right" solution, in general, you just need to list of the pros and cons of each approach with respect to your project and decides what's right for you.

Thanks. I see I was not precise enough. What I have here is a legacy code - it is one huge class (i.e. package) split into many files for easier editing. This splitting breaks the usual assumption about the correspondence between the file name and the package contained in it. I guess I can live with that if I have - but it would nice to at least organise my new code in a more intuitive (i.e. standard) way. I am now looking into C:A:Dispatch - it is promising.

use App::Class;

App::Class->new()->run();
[download]

use Config::myTiny;
sub readconfig {
  my $self=shift;
  my $cfg=$0;
  $cfg=~s/\.pl$/.ini/;
  my $conf=Config::myTiny->read($cfg);
  $conf=Config::myTiny->new() unless $conf;

  $self->{config}=$conf;
}
[download]

sub run {
  my $self=shift;
  $self->readconfig();
# ...
  if ($self->{config}->get('options','showonstartup')) {
    $self->show_mainwindow();
  }
# ...
}
[download]

• use base qw(Your::Base::App);
• if you can isolate something, you can turn it into an object