I'd convert each 'module' into a real Perl module( YourPackage::Search.pm
etc ) and then configure it at the directory level.
<Location /search>
SetHandler perl-script
PerlHandler YourPackageSpace::Search
</Location>
Or you can just take your script and throw it into a single module's
handler() routine :
<Location />
SetHandler perl-script
PerlHandler YourPackageSpace::YourNewModule
</Location>
Your modules will be pre-compiled and your source is much more manageable in
the future for other people involved in the project. I find it best to
'break' the boundary between CGI and ModPerl by generally _not_ writing
'.pl' scripts and instead moving everything into pure modules. It just makes
the conceptual jump between CGI and mod perl much easier for newbies who
join the team. I'm sure it has performance and integration impacts that I am
not to knowledgeable on though.
John-
On 6/11/01 10:28 AM, "Purcell, Scott" <[EMAIL PROTECTED]> wrote:
> Hello,
> I have a large asset-management system that is web-based. In the past I have
> always used cgi and perl. I need to rewrite it so that it works with
> mod-perl or PerlEx....
> Anyway, I used to tie my site together with a main, and a ton of requires
> (which required pages of subroutines). I would use a hidden variable to do
> the navigation. So each time the user hit something, I directed them back to
> the main and used a hidden variable to go spawn a different subroutine. So
> it was basically a nested application. The site got large (a lot of perl
> code, over 20,000 lines), and it got slow because each user ended up
> recompiling the code for each submit.
>
> Lately as I am thinking about rebuilding the site, but not using a nested
> config, but just offering each page to be its own perl file. So when the
> user submits for a search, I just point them at the search.pl file. Sounds
> simple enough, but I work alone, and do not know how the world builds large
> sites. I was hoping to hear some simple input from people who have
> architected good, sound sites, and was hoping for some good feedback, or
> some old sample code that I can study and find out how the other half live.
>
> I hope this is not asking too much, Any input would be most helpful.
>
> Sincerely
>
> Scott Purcell
>
>
