Re: Questions Concerning Large Web-Site
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
Re: Questions Concerning Large Web-Site
Purcell, Scott [EMAIL PROTECTED] wrote: 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. Well, I can give some things I've tried to live by. (1) Keep each component simple - it's a lot easier to debug. (2) Never depend on hidden variables telling you which page you are on -- look at the data and see which page the data fits best. This increases security. I typically make one script per task and let the script figure out which page to show. Cf. TWIG, which has a single controlling script (index.php3). (3) Build a solid foundation - makes the user interface almost trivial and easier to manage when policies change. This usually consists of a set of libraries to do the actual work. (4) If it's on CPAN, try to use it. Better to use someone else's work (if it fits) then reinvent the wheel. You might want to check out some of the templating packages available. If you want a framework, take a look at Mason. (5) Even for a single developer, revision control can be nice. These (except the CPAN part) are based on my experience with a PHP project that I am working on (yes, different language but same rules) which consists of around 50,000 lines of code, unfinished (email and directory service management for customers based on TWIG). John's email has some good suggestions specific to Perl. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: Questions Concerning Large Web-Site
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
Re: Questions Concerning Large Web-Site
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
RE: Questions Concerning Large Web-Site
I like Writing Apache Modules with Perl and C from O'Reilly (ISBN: 1-56592-567-X). -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) -Original Message- From: Ron Beck [mailto:[EMAIL PROTECTED]] Sent: Monday, June 11, 2001 2:42 PM To: John Armstrong Cc: '[EMAIL PROTECTED]' Subject: Re: Questions Concerning Large Web-Site 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
Re: Questions Concerning Large Web-Site
[EMAIL PROTECTED] (Ron Beck) 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. I've written one, at http://www.mathforum.com/~ken/perl_modules.html It's general-purpose, not Apache or mod_perl specific. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Questions Concerning Large Web-Site
On Mon, 11 Jun 2001, Ron Beck 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. There's a good intro (though I'm biased) on http://take23.org/ -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: Questions Concerning Large Web-Site
There is a tutorial here http://savage.net.au/Perl-tutorials.html#tut-1 on a Perl program which generates the source of a module, installs and tests it. Cheers Ron Savage [EMAIL PROTECTED] http://savage.net.au/index.html [snip] 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 [snip]
