On Wed, 15 Sep 2004, hcohen2 wrote: > Chris Devers wrote: > > > On Wed, 15 Sep 2004, hcohen2 wrote: > > > > > However, there is a reader's review of the first edition that seems to > > > ring true and, moreover, is not complimentary. > > > > > > > ...and the URL for that is... ? > > > > Here? <http://www.amazon.com/exec/obidos/tg/detail/-/0966942604> > > > http://www.amazon.com/exec/obidos/ASIN/0966942612/qid=1095287768/sr=ka-2/ref=pd_ka_2/104-9750707-3239905 > > No on this page, also well down the page - here is a partial quote: > > "The first 40 pages are useful to give you the sense of how CGI functionality > is implemented in Perl. However by staying away from the most used standard > Perl module for CGI programming (i.e. the CGI module) except for a few pages > towards the end, the reader is ill served ..."
That quote appears on the URL I sent :-) > The criticism was that the CGI.pm was not hardly at all and only near > the end of the book. In that case then, the point is fair. > > You may want to look at the _Official Guide to Programming with CGI.pm_, > > I scanned a copy, but I think for now it has too much depth for my purposes. Suit yourself. > > Learning mod_perl can be much more daunting than CGI -- hence the > > continuing popularity of CGI over mod_perl for new learners -- but > > in the long run it would be much more useful to understand mod_perl. > > If I thought that I would be doing nothing else other than building > web site back ends this might be a valid approach. However, I am > really a database applications programmer and at least part of me has > be focused on that sort of an end product. So what? Using mod_perl doesn't mean not using databases. On the contrary, with mod_perl you can develop applications that maintain a persistent, stable connection to your database server, with each page request being turned into one or more SQL requests to the database made by way of that static connection. By contrast, every hit on a CGI script is a discrete, atomic event. The Perl interpreter needs to be established from scratch, then it needs to load the (possibly heavy) DBD database driver, then the transaction with the database happens, then everything is torn back down. If you have a busy site, all this machinery gets loaded and unloaded over and over again with each request. This is slow! If you use Apache::Registry, traditional CGI scripts can in most cases be run with very little modification as mod_perl scripts. You often don't need to change a line of code, as long as you've been writing scripts that follow certain guidelines. But you get most of the benefits of the mod_perl environment automatically: the Perl interpreter and libraries are persistent in memory, so you don't prefix each request with loading everything and finish by tearing it all back down. You get to, almost for free, have a much faster site that can handle many, many more concurrent users. mod_perl is, in short, every bit worth the effort to learn. > Hence, a complete switch > to mod_perl is too speculative for me to take that path. "Speculative"? Are you afraid it's going away? That is highly unlikely. -- Chris Devers -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
