The "Eagle" book ( linked to from http://perl.apache.org/ ) is a good
resource.
Generally speaking though you can get what you need to start in the guide (
http://perl.apache.org/guide/ ), its pretty simple to get started.
John-
On 6/11/01 12:42 PM, "Ron Beck" <[EMAIL PROTECTED]> wrote:
>
> Is there a good tutorial or book on the subject of constructing Perl
> modules? I too have done some of this and would like to create actual
> modules instead of required subroutines.
>
> Ron
>
> John Armstrong wrote:
>>
>> 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
>>>
>>>
>
