Large websites mean that you have a lot of code. To keep the site flexible and maintainable, you should keep the Perl code and the HTML separate. Likewise, I suggest you template your navigation as well. Done properly, this means you can change the "look and feel" of your site by changing one set of templates that will affect all your pages. You should also make your own code as modular as possible. That way you don't have identical code in 15 scripts.

The other concern doesn't deal with number pages, but instead amount of traffic, in which case you are interested in efficency. The answer there is mod_perl. Most of the templating sytems (all of the major ones) are mod_perl friendly, as far as I know.

CGI::Application is indeed "just a way to avoid 'if-then' statements", but you can also use it (or any setup like it) as a central point for your code. You could make a sub-class that all of your scripts are sub-classes of, and should you need to update anything, you can update your super-class and have all of your scripts updated instantly. THis is what object-oriented programming is all about.

CGI::App isn't really a templating system. HTML::Template, HTML::Mason, HTML::Embperl and Template::Toolkit are templating systems.

We can't use mod_perl because we use ISAPI and IIS. I don't have any choice in that.

I'm not sure if you answered my main question. You said number of pages isn't important, but amount of traffic. What I was wondering is whether or not it is a good idea to break one script down into a bunch of smaller scripts, with the main script 'requiring' the smaller scripts as needed (one script per screen). The pro seems to be that smaller amounts of Perl are loaded. The con seems to be many more scripts. Sorry if my question was not clear.

Sorry I missed that ISAPI part.

THe comment about number of pages vs traffic was changing the definition of "large websites". If you are more concerned about the number of pages you have to maintain, here's my advice (My sites haven't had more than 350 pages, although those were doubled up in text and graphic versions to near 700, so take this advice with the appropriate amount of salt).

Rather than break it down into smaller scripts, Move as much code as you can into modules. If something shows up in more than one script, it's worth modularizing (this is basically what you were saying, but modules are cleaner than scripts, you aren't trampling the same namespace).

If you break your HTML away from your Perl code, you can reduce your HTML maintenance requirements, and can have non-coders write HTML. This is what the templating systems are for.

Since you don't have mod_perl, I'd suggest looking into HTML::Template. CGI::Application could help you, because it can let you reuse the same code for multiple scripts, but it isn't essential.

Really I think you have the right idea, but if you Modularize your code, it will be cleaner. More modules can be easier to maintain than fewer but longer scripts, because you don't have to worry about trampling namespaces, and the purpose of the code is more clear-cut.

Hope that helps.

• Take a leap and go the PerlHandler route. It's not as simple as CGI, but this will alow you to easily separate the site into different functional layers.
• Separate the html completely from the logic. The benefits of this are far to great to list here.
• Don't be afraid to have lots of utility libraries. It will save you lots of code replication (and debugging, etc..).
• objects and inheritance are your friends.

I realize that you're running IIS (you have my sympathy), but you can still make use of the techniques. You may also want to consider a minor porting task on your own if you want to get away from IIS. In one case we were locked in to using MSQL, I took it upon myself to port the database to MySQL on Linux. The benchmarks were convincing enough to move to MySQL (a factor of 10 speed increase). Often just saying there's a better way is just ignored, have benchmarked or demonstratable proof is harder to ignore.

Good luck,

/\/\averick