[22545] in Perl-Users-Digest
Perl-Users Digest, Issue: 4766 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 27 18:11:11 2003
Date: Thu, 27 Mar 2003 15:10:34 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 27 Mar 2003 Volume: 10 Number: 4766
Today's topics:
Re: CGI.pm or roll-your-own? <nwzmattXX@XXnetscape.net>
Re: CGI.pm or roll-your-own? <tore@aursand.no>
Re: CGI.pm or roll-your-own? <nwzmattXX@XXnetscape.net>
Re: CGI.pm or roll-your-own? <bkennedy@hmsonline.com>
Re: CGI.pm or roll-your-own? <tore@aursand.no>
Re: CGI.pm or roll-your-own? <noreply@gunnar.cc>
Re: CGI.pm or roll-your-own? <me@privacy.net>
Re: CGI.pm or roll-your-own? <flavell@mail.cern.ch>
Re: CGI.pm or roll-your-own? <pkent77tea@yahoo.com.tea>
Re: CGI.pm or roll-your-own? (Helgi Briem)
Re: CGI.pm or roll-your-own? (William C. Ray)
Re: CGI.pm or roll-your-own? <flavell@mail.cern.ch>
Re: CGI.pm or roll-your-own? (Randal L. Schwartz)
Re: CGI.pm or roll-your-own? (Tad McClellan)
Re: CGI.pm or roll-your-own? (William C. Ray)
Re: CGI.pm or roll-your-own? (William C. Ray)
Re: Database Application Development with Perl / Gtk / <pkent77tea@yahoo.com.tea>
Re: Database Application Development with Perl / Gtk / <goldbb2@earthlink.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 26 Mar 2003 16:53:57 GMT
From: Matt <nwzmattXX@XXnetscape.net>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <uy932b5da.fsf@XXnetscape.net>
helgi@decode.is (Helgi Briem) writes:
> But "why?" Why do people, beginners no less, constantly
> want to write this themselves when using the CGI module
> is almost infinitely easier (not to mention better).
I contemplated using CGI.pm recently in some scripts I was writing. The
thing was that I didn't need all of the features of it. In most, all I
needed to do was to parse the form data. In others, just set a simple
cookie. No HTML output, no anything else. It seemed too costly to load
the entire module just for that. Of course there are alternatives,
such as CGI-Lite, and CGI-Tiny. The problem here is that they are not
core modules, and so are prone to go unmaintained, which looks to be
the case with CGI-Lite now.
>
> This applies not only to CGI.pm, but to modules in
> general. Why are so many people reluctant to
> use modules? It puzzles me.
>
I think that in some cases, they just may not know about some of the
modules included in the distribution, or are not quite sure how to use
them. A beginner may be struggling to get a handle on perl itself,
and are not ready to go diving into a module and trying to learn the
methods it provides, especially if a module returns a complex data
structure, or requires the use of objects.
<snip>
> Are C programmers too proud to start their programs
> with #include stdio.h and insist on writing
> it themselves?
>
No, but those are core libraries. Trying to use non core modules from
CPAN can become a problem later on down the line, especially if the
code needs to be portable.
I agree though. All perl programmers should be aware of the modules
that are provided with a perl distribution, and at least consider using
them first before trying to roll their own.
Matt
--
Remove the X's to reply directly.
------------------------------
Date: Wed, 26 Mar 2003 18:28:18 +0100
From: "Tore Aursand" <tore@aursand.no>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <pan.2003.03.26.17.27.41.269904@aursand.no>
On Wed, 26 Mar 2003 16:53:57 +0000, Matt wrote:
>> But "why?" Why do people, beginners no less, constantly want to write
>> this themselves when using the CGI module is almost infinitely easier
>> (not to mention better).
> I contemplated using CGI.pm recently in some scripts I was writing. The
> thing was that I didn't need all of the features of it. In most, all I
> needed to do was to parse the form data. In others, just set a simple
> cookie. No HTML output, no anything else. It seemed too costly to load
> the entire module just for that.
"It seemed to"? In other words, you did a benchmark on this? Loading the
whole CGI module isn't especially costly, but initialising it might take
some unnecessary time in certain environments.
--
Tore Aursand
------------------------------
Date: Wed, 26 Mar 2003 18:50:15 GMT
From: Matt <nwzmattXX@XXnetscape.net>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <uel4uvu6v.fsf@XXnetscape.net>
"Tore Aursand" <tore@aursand.no> writes:
> On Wed, 26 Mar 2003 16:53:57 +0000, Matt wrote:
> >> But "why?" Why do people, beginners no less, constantly want to write
> >> this themselves when using the CGI module is almost infinitely easier
> >> (not to mention better).
>
> > I contemplated using CGI.pm recently in some scripts I was writing. The
> > thing was that I didn't need all of the features of it. In most, all I
> > needed to do was to parse the form data. In others, just set a simple
> > cookie. No HTML output, no anything else. It seemed too costly to load
> > the entire module just for that.
>
> "It seemed to"? In other words, you did a benchmark on this? Loading the
> whole CGI module isn't especially costly, but initialising it might take
> some unnecessary time in certain environments.
>
No I didn't, but others have. Have a look at
http://search.cpan.org/src/JFREEMAN/Cgi-Simple-0.06/cgi-simple_vs_cgi-pm.html
CGI.pm is a very good module, but is big and sometimes
unnecessary.
BTW, in my original followup post, I meant to say CGI-Simple, not
CGI-Tiny.
Matt
--
Remove the X's to reply directly.
------------------------------
Date: Wed, 26 Mar 2003 14:50:49 -0500
From: "Ben Kennedy" <bkennedy@hmsonline.com>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <FK6cnZFZm44HmR-jXTWcqQ@giganews.com>
"Matt" <nwzmattXX@XXnetscape.net> wrote in message
news:uel4uvu6v.fsf@XXnetscape.net...
>
> CGI.pm is a very good module, but is big and sometimes unnecessary.
>
The problem is that it is hard to find a real-world example where this speed
makes any bit of difference - if you care about speed in the first place,
you would have used a non-CGI environment such as mod_perl. The only time
the not use CGI.pm in production is when you absolutely need to shave tiny
fractions of a second from your response time, and for some reason you
absolutely can't use mod_perl and friends. Generic bencharks say very
little about the usefulness of a module in your particular application.
--Ben Kennedy
------------------------------
Date: Wed, 26 Mar 2003 21:04:17 +0100
From: "Tore Aursand" <tore@aursand.no>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <pan.2003.03.26.19.47.01.757827@aursand.no>
On Wed, 26 Mar 2003 18:50:15 +0000, Matt wrote:
>>> I contemplated using CGI.pm recently in some scripts I was writing.
>>> The thing was that I didn't need all of the features of it. In most,
>>> all I needed to do was to parse the form data. In others, just set a
>>> simple cookie. No HTML output, no anything else. It seemed too costly
>>> to load the entire module just for that.
>> "It seemed to"? In other words, you did a benchmark on this? Loading
>> the whole CGI module isn't especially costly, but initialising it might
>> take some unnecessary time in certain environments.
> No I didn't, but others have. Have a look at [...]
I've seen that one before, and it's a perfectly valid benchmark comparison
as long as you're _not_ running mod_perl (or equivalent solutions).
However, the points that the comparision is trying to make, isn't valid in
a real world scenario; CGI.pm is having _no_ problems doing its task as
fast as required as long as you're not running mod_perl. Other things
will stopp the CGI application from working; web server load, the general
application flow (ie. execution speed) etc.
So - in the end - it won't be CGI.pm that's making your CGI application
(and, eventually, the whole web server) to crawl and die.
--
Tore Aursand
------------------------------
Date: Wed, 26 Mar 2003 21:50:08 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <b5t3q7$2crb16$1@ID-184292.news.dfncis.de>
Tintin wrote:
> I ... just include local copies on the [non-standard] modules my
> software uses.
>
> Sure it makes the distribution a bit bigger, but it certainly makes
> development much easier.
I do the same. It's the way to go, I think, if you expect your program
to be used by beginners.
Alan J. Flavell replied:
> That's a double-edged sword, though. Although it seems easier in the
> first instance, and might reduce _your_ maintenance commitment a
> little bit if they are sure to use the frozen version of the module
> that you bundle with your distribution, it does mean that any
> improvements, bugfixes - especially security fixes - to the
> constituent modules will need to be installed specially, rather than
> coming from the module's own home.
True. But I suppose you agree that if the alternative is to not make
use of non-standard modules at all, it's better to include specific
versions of them.
Also, there is no guarantee that a later version of a (non-standard)
module is backwards compatible. A few weeks ago I was about to replace
the modules included in a program distribution with the latest
versions. In one case (it was Archive::Zip), the upgrade would have
required modifications in my program, and since I saw no advantages
with doing that, for the time being I keep including an older version
of that module.
/ Gunnar
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Thu, 27 Mar 2003 08:51:34 +1100
From: "Tintin" <me@privacy.net>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <b5t7d7$2d09fj$1@ID-172104.news.dfncis.de>
"Alan J. Flavell" <flavell@mail.cern.ch> wrote in message
news:Pine.LNX.4.53.0303261318320.4023@lxplus090.cern.ch...
> On Wed, Mar 26, Tintin inscribed on the eternal scroll:
>
> > Speaking personally, I tried to avoid using non-standard modules in my
> > software that I distributed, as I found that beginners would get very
stuck
> > trying to install a required module. However, I changed my mind on that
> > one, and just include local copies on the modules my software uses.
>
> That's a double-edged sword, though. Although it seems easier in the
> first instance, and might reduce _your_ maintenance commitment a
> little bit if they are sure to use the frozen version of the module
> that you bundle with your distribution, it does mean that any
> improvements, bugfixes - especially security fixes - to the
> constituent modules will need to be installed specially, rather than
> coming from the module's own home.
Proably should have mentioned that my code checks to see if the required
module is already installed on the system, if not, use my local copy.
------------------------------
Date: Wed, 26 Mar 2003 22:22:50 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <Pine.LNX.4.53.0303262221350.4023@lxplus090.cern.ch>
On Wed, Mar 26, Gunnar Hjalmarsson inscribed on the eternal scroll:
> > That's a double-edged sword, though. Although it seems easier in the
> > first instance, and might reduce _your_ maintenance commitment a
> > little bit if they are sure to use the frozen version of the module
> > that you bundle with your distribution,
[...]
> Also, there is no guarantee that a later version of a (non-standard)
> module is backwards compatible.
Indeed: that's exactly why I said what you've quoted above.
cheers
------------------------------
Date: Thu, 27 Mar 2003 00:24:48 GMT
From: pkent <pkent77tea@yahoo.com.tea>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <pkent77tea-7A8EEB.00175227032003@[10.1.1.10]>
In article <3e817fe5.4055961764@news.cis.dfn.de>,
helgi@decode.is (Helgi Briem) wrote:
> But "why?" Why do people, beginners no less, constantly
> want to write this themselves when using the CGI module
> is almost infinitely easier (not to mention better).
OK point for the defense: implementing stuff from scratch can be a good
learning experience (like typing "GET / HTTP/1.0\n\n" or "MAIL FROM:
root\nRCPT TO:...") and I guess that these beginners may be new to Perl
but very experienced in HTTP, or C, or TCP or whatever.
Still, in all my time programming professionally no-one has ever even
mentioned using something other than CGI, in a business setting. Maybe
that's cos we use shedloads of mod_perl serving capacity, and the plain
CGI stuff runs on shedloads of rather nippy Sun enterprise servers...
heck, it's all way fast enough even on my cobalt raq :-) and that's
hardly powerful.
> This applies not only to CGI.pm, but to modules in
> general. Why are so many people reluctant to
> use modules? It puzzles me.
I don't see quite so many posts saying "This pesky DBD::Oracle is big
and clunky! How can I make it faster!" :-) Seriously, CGI.pm must be
tens of times more commented on than any other module. Why can't they
rewrite, I don't know, Data::Dumper for a change.
> Do C++ programmers start out writing the
> equivalent of the STL before writing a program?
Well I did try to implement my own kind of string object in C... maybe
that counts :-)
P
--
pkent 77 at yahoo dot, er... what's the last bit, oh yes, com
Remove the tea to reply
------------------------------
Date: Thu, 27 Mar 2003 09:24:56 GMT
From: helgi@decode.is (Helgi Briem)
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <3e82c1f8.4138419342@news.cis.dfn.de>
On Thu, 27 Mar 2003 00:24:48 GMT, pkent
<pkent77tea@yahoo.com.tea> wrote:
>> This applies not only to CGI.pm, but to modules in
>> general. Why are so many people reluctant to
>> use modules? It puzzles me.
>
>I don't see quite so many posts saying "This pesky DBD::Oracle is big
>and clunky! How can I make it faster!" :-) Seriously, CGI.pm must be
>tens of times more commented on than any other module. Why can't they
>rewrite, I don't know, Data::Dumper for a change.
No, I think its because beginners don't write programs
that interact with Oracle databases. Pros do that.
Pros use the module. If the pro finds that the module
isn't doing the job as well as it could, (s)he submits a
patch to the author or to CPAN instead of writing a new
driver.
Beginners want form to mail or a guestbook for their
Counterstrike website. They pick up some P of S code from
Ma**'s Sc***t A**chive or somewhere, can't get it to work,
ask how and then get all defensive when someone tells them
to do themselves a favour and use the CGI module.
--
Regards, Helgi Briem
helgi DOT briem AT decode DOT is
------------------------------
Date: 27 Mar 2003 10:16:51 -0500
From: ray@soyokaze.biosci.ohio-state.edu (William C. Ray)
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <b5v4l3$p9k@soyokaze.biosci.ohio-state.edu>
Eric Schwartz wrote:
>> Greg Raven <usrsa@racquettech.com> writes:
>> Good point. I have been moderately successful up until now hammering out
>> ugly but function perl scripts. Adding CGI.pm to the mix seems likely to
>> set me back at least temporarily, and the authors of Mac OS X Unleashed
>> advise against getting involved in it if possible.
> I'd be very skeptical of that book if it indeed advocates against
> CGI.pm;
To be fair, we wrote a Mac OSX book, not a Perl programming book. It
is noted throughout the text that there are almost always more advanced
references, with much more information on specific topics such as the
Perl programming language, and that readers who want to go beyond what we
cover, or become fluent in any of these specific areas need to consult
the appropriate specific references. In light of this, the Perl section
included in MacOS X Unleashed is intended to be a "flavor of" primer that
hopefully will provide enough information that incoming Macintosh users
who've never thought of writing a bit of code before, might find that it's
interesting and easy enough to actually give the commandline a go.
That being said, I probably wouldn't have put the comments regarding
CGI.pm in the same way that John did, but I do agree with his assessment
that in practice CGI.pm is unnecessarily daunting to the novice programmer,
especially if they're novice programmers who are coming from a world
where they never thought of touching the keyboard of their computer.
I wouldn't specifically caution Greg, or other novice Perl programmers
against using CGI.pm, but I also wouldn't suggest it as a module that
a Mac user who's just conquered a Perl version of "Hello World" will
be comfortable with.
Also of note, Greg pointed out in email that a code snippet included
in the book is suspiciously similar to a fragment of cgi-lib.pl,
and was printed without attribution, and rather badly mangled at that.
Unfortunately, this fragment made its way to John without attribution,
and was included in the book with a specific note of our lack of knowledge
of its true origin. We are truly sorry to have included a version of
Steve Brenner's work without proper attribution and will be correcting
the text for the next printing, and publishing a correction note on our
website immediately.
We're also sorry to have included the fragment
without examining it carefully enough to note that due to mangling of
the original, it's not entirely functional, and certainly isn't an example
of good Perl. How it made it past two written revisions, and two rounds
of technical editors, we do not know, but it serves as yet another
example for posterity of why neglecting to use strict is a bad thing.
Will Ray
coauthor, MacOS X Unleashed
------------------------------
Date: Thu, 27 Mar 2003 17:34:17 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <Pine.LNX.4.53.0303271701200.25187@lxplus087.cern.ch>
On Thu, Mar 27, William C. Ray inscribed on the eternal scroll:
> That being said, I probably wouldn't have put the comments regarding
> CGI.pm in the same way that John did, but I do agree with his assessment
> that in practice CGI.pm is unnecessarily daunting to the novice programmer,
Tutorials and recipes are freely available, ranging from the
elementary to the quite complex (you don't have to buy the
accompanying book in order to use the online recipes, for example).
(Not that I'm trying to discourage anyone from buying the book.)
> especially if they're novice programmers who are coming from a world
> where they never thought of touching the keyboard of their computer.
Are you suggesting that understanding the minutiae of GET v. POST,
x-form-url-encoded format, the distinctions between RFC2616 and
the CGI specification, between parsed-headers and NPH scripts, and so
on ad nauseam, would be any less daunting to the novice programmer?
CGI.pm can take care of all that for them.
> I wouldn't specifically caution Greg, or other novice Perl programmers
> against using CGI.pm, but I also wouldn't suggest it as a module that
> a Mac user who's just conquered a Perl version of "Hello World" will
> be comfortable with.
Let's hope that such a person isn't writing production server-side
scripts of any kind yet. I wouldn't for a moment want to discourage
them from exploring the language - quite the opposite, in fact - but
they should be tackling tasks which, while challenging for their
present level, are still within reach of their capabilities in order
to get something useful (and satisfying) out of the exercise.
IMHO and YMMV, naturally.
------------------------------
Date: Thu, 27 Mar 2003 18:22:35 GMT
From: merlyn@stonehenge.com (Randal L. Schwartz)
To: ray@soyokaze.biosci.ohio-state.edu (William C. Ray)
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <509b3630abaf9f679c15b75f1866e1d0@news.teranews.com>
>>>>> "William" == William C Ray <ray@soyokaze.biosci.ohio-state.edu> writes:
William> That being said, I probably wouldn't have put the comments regarding
William> CGI.pm in the same way that John did, but I do agree with his assessment
William> that in practice CGI.pm is unnecessarily daunting to the novice programmer,
William> especially if they're novice programmers who are coming from a world
William> where they never thought of touching the keyboard of their computer.
William> I wouldn't specifically caution Greg, or other novice Perl programmers
William> against using CGI.pm, but I also wouldn't suggest it as a module that
William> a Mac user who's just conquered a Perl version of "Hello World" will
William> be comfortable with.
Bull-oney.
In the same way that you have:
#!/usr/bin/perl
... 40 lines of cgi-lib cargo-cult crap ...
my $name = $FORM{name};
my $age = $FORM{age};
... rest of program ...
You can instead have:
#!/usr/bin/perl
use CGI "param";
my $name = param('name');
my $age = param('age');
... rest of program ...
You don't have to change a single other thing.
I do *not* accept any argument that CGI.pm is *harder* than the
hand-rolled-parsing buggy cargo-cult-crap. That's just plain crazy.
print "Just another Perl hacker,"
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Thu, 27 Mar 2003 13:25:50 -0600
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <slrnb86k1u.4ck.tadmc@magna.augustmail.com>
William C. Ray <ray@soyokaze.biosci.ohio-state.edu> wrote:
[ snip already-done-by-expert vs. rewrite-it-all-by-beginner,
or maybe it's:
do-it-all-myself vs. let-someone-else-do-it-I'll-write-less-code
]
> CGI.pm is unnecessarily daunting to the novice programmer,
CGI _programming_ is unnecessarily daunting to the novice programmer.
It isn't the module that brings the complexity, it is the
chosen application area.
CGI is a somewhat advanced application, beginners should not be
doing CGI programming. (but they are going to anyway, I know)
> where they never thought of touching the keyboard of their computer.
If they use CGI.pm, then they will never have to think about
decoding a URL or getting form values.
If they don't, then they "get to" learn all of that in addition
to learning Perl, and perhaps to programming itself.
> I wouldn't specifically caution Greg, or other novice Perl programmers
> against using CGI.pm, but I also wouldn't suggest it as a module that
> a Mac user who's just conquered a Perl version of "Hello World" will
> be comfortable with.
That is pretty absurd.
Rather than have them learn the 2 lines of code they'd need
with CGI.pm, you would have them learn a Whole Lot More lines
of punctuation-intensive gobbledy gook?
How can that be better for an already overloaded beginner?
I'm not seeing it...
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 27 Mar 2003 16:12:15 -0500
From: ray@soyokaze.biosci.ohio-state.edu (William C. Ray)
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <b5vpff$qf5@soyokaze.biosci.ohio-state.edu>
In article <509b3630abaf9f679c15b75f1866e1d0@news.teranews.com>,
Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>Bull-oney.
>
>In the same way that you have:
>
> #!/usr/bin/perl
>
> ... 40 lines of cgi-lib cargo-cult crap ...
...
>You can instead have:
>
> #!/usr/bin/perl
>
> use CGI "param";
...
>You don't have to change a single other thing.
>
>I do *not* accept any argument that CGI.pm is *harder* than the
>hand-rolled-parsing buggy cargo-cult-crap. That's just plain crazy.
Randal, I greatly respect what you've accomplished and done for the Unix
and Perl communities, but please allow that John and I have some feel
for our audience here.
Traditional Macintosh users migrating to OS X are a very strange
phenomenon, and in many ways they tend to "Think Different". I'll
not for a moment suggest that using CGI.pm _is_ harder, but from
a practical standpoint, to the novice it looks like a black box with
a button on it that says "Solve My Problems". The typical traditional
Mac user, as much as they've always wanted and used an OS with exactly
that type of black-box functionality, for some reason, doesn't take
well to that at the command-line. In my experience, they feel much
more comfortable with something with not too intimidating guts, that
they can see the internals of and see that it's not as complex as
they might have imagined, and that they can at least imagine
understanding if they devoted the time to following the logic. CGI.pm
simply doesn't fit where I think most traditional Mac users are
going to be willing to play, at least at the outset.
If the popularity of homebrewed parsing code on the 'net is any
indication, for some reason, it's also outside the scope of where a
great many others feel that they are comfortable as well. Right or
wrong (and I see no logic that suggests that it's right), in practice
CGI.pm seems to give many the initial impression that it'd be
easier to hack something together themselves than to take the time
to learn CGI.pm. Avoiding that (unwarranted, but obviously real
enough) initial negative impression is my sole concern when I say that
mixing CGI.pm and novice Mac Perl programmers may not be a very
good idea without a very gentle introduction.
That being said, I'll also comment that I'd probably have done the
section differently. John's the happy, touchy-feely GUI, Perl/Applescript,
web stuff guy, and I'm the grouchy, pedantic, command-line, GNU stuff,
security, etc. curmudgeon. I'd probably have avoided CGI.pm in that
section in favor of 5 or 10 lines much simpler than the cgi-lib.pl
parsing stuff that was included, so that I could use those 5 or 10
lines as direct educational examples regarding the language's parsing
capabilities, and also examples of how a simplistic parsing approach
can fail. And then I'd probably have turned around and showed them how
to do it with CGI.pm as an example of the right way to do it, just
because it'd be good for them. But, I'm the curmudgeon, and I can
get away with that. John's writing style and temperament don't lend
themselves to that approach.
Still, now that I've read through the section, I can see that we'll
have to re-work that a bit in the next edition. I spend a good
portion of the command-line chapters trying to educate the readers
regarding the Unix culture that they've suddenly been dropped into,
and how to behave like conscientious citizens in the culture, and
sending them off to comp.lang.perl.* with bad questions about bad
code isn't one of the things I'd hoped we'd have them doing.
Will Ray
coauthor, MacOS X Unleashed
------------------------------
Date: 27 Mar 2003 16:59:48 -0500
From: ray@soyokaze.biosci.ohio-state.edu (William C. Ray)
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <b5vs8k$qmd@soyokaze.biosci.ohio-state.edu>
In article <Pine.LNX.4.53.0303271701200.25187@lxplus087.cern.ch>,
Alan J. Flavell <flavell@mail.cern.ch> wrote:
>On Thu, Mar 27, William C. Ray inscribed on the eternal scroll:
>> especially if they're novice programmers who are coming from a world
>> where they never thought of touching the keyboard of their computer.
>
>Are you suggesting that understanding the minutiae of GET v. POST,
>x-form-url-encoded format, the distinctions between RFC2616 and
>the CGI specification, between parsed-headers and NPH scripts, and so
>on ad nauseam, would be any less daunting to the novice programmer?
Oh my no. I'm suggesting that from a realistic standpoint, we would be
delighted if 10% of the readers went so far as to actually implement the
cgi-script example that takes no parameters at all, and simply acts on
server-side data ( a 9-line Perl script that lists the contents of
a fixed directory on the server ). The highest aspirations we have
for the results of including a Perl section in the book is that a
few of the readers will find it interesting enough, understandable
enough, and simple enough that they can incorporate the automation of
simple tasks using Perl into their repetoire.
Readers who need to understand minutiae are repeatedly informed that we
can provide only a glancing view of the tip of the iceberg, and that
there are a multitude of resources available to them from which to
learn not only more information, but better practices as well.
The inclusion of a 20-line version of what looks to be Steve Brenner's
ReadParse routine was simply as a way to demonstrate, in a simple enough
chunk of code that its function could be explained in a line-by-line
fashion, how small a step it is from static cgi scripts, to ones
that can accept values from submitted forms.
>CGI.pm can take care of all that for them.
CGI.pm doesn't solve the educational need. Yes, it will do the
parsing _better_ but it's neither small enough, nor simple enough that
a novice reader can look at it and reasonably believe that they
understand what it's doing and how it's doing it. For a massive
audience of readers who've up until now, been told that using the
keyboard to control their computers was some sort of plot from the
dark side, feeling like they understand what's going on is a large
portion of accepting the technology.
I can see I need to stick my pedantic nose in John's chapter here
on the next revision, as I firmly believe in telling the reader
the right way to do things, but I'll stick by my assertion that
the average traditional Mac reader risks being turned off by a bare
use of CGI.pm with no-more explanation than we have space to devote to
it in the book. Crafted properly, shown as the proper solution,
with little auxilliary discussion, after we've shown them the guts
of something simple that can be explained and understood, it might
fly, but bare, no.
>Let's hope that such a person isn't writing production server-side
>scripts of any kind yet. I wouldn't for a moment want to discourage
>them from exploring the language - quite the opposite, in fact - but
>they should be tackling tasks which, while challenging for their
>present level, are still within reach of their capabilities in order
>to get something useful (and satisfying) out of the exercise.
Hehehe - care to guess the title of the fellow who email
recently asking how to find the /etc/ directory?
Will Ray
coauthor, MacOS X Unleashed
------------------------------
Date: Thu, 27 Mar 2003 00:54:49 GMT
From: pkent <pkent77tea@yahoo.com.tea>
Subject: Re: Database Application Development with Perl / Gtk / Tk
Message-Id: <pkent77tea-517EC8.00282727032003@[10.1.1.10]>
In article <f0687d72.0303252333.111fdcdf@posting.google.com>,
bharat@ZONNET.NL (Bharat Pondugula) wrote:
> I am looking for guidance regarding the above subject. I am planning
> to build an application (pretty database intensive about a million
> records ) with GUI frontend in either PERL GTK or PERL TK. Do you
> think that the application will be fast enough.
I'd say a definite "yes" unless you have some unusual setup or
application. For a start the interface is running on the local machine
which is good. I don't think the table size necessarily makes a
difference unless you're planning on displaying 'SELECT * FROM
maintable' on the client. A million text widgets might take some serious
processing to manage.
P
--
pkent 77 at yahoo dot, er... what's the last bit, oh yes, com
Remove the tea to reply
------------------------------
Date: Wed, 26 Mar 2003 23:31:51 -0500
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Database Application Development with Perl / Gtk / Tk
Message-Id: <3E827EB7.3D4473BC@earthlink.net>
pkent wrote:
>
> In article <f0687d72.0303252333.111fdcdf@posting.google.com>,
> bharat@ZONNET.NL (Bharat Pondugula) wrote:
>
> > I am looking for guidance regarding the above subject. I am planning
> > to build an application (pretty database intensive about a million
> > records ) with GUI frontend in either PERL GTK or PERL TK. Do you
> > think that the application will be fast enough.
>
> I'd say a definite "yes" unless you have some unusual setup or
> application. For a start the interface is running on the local machine
> which is good. I don't think the table size necessarily makes a
> difference unless you're planning on displaying 'SELECT * FROM
> maintable' on the client.
That depends on *how* you're choosing to display that query.
Keep in mind, you can only have some number of rows (call this N) on the
screen at once.
So, you'd create N text widgets, and a scrollbar.
Change the query to:
SELECT * FROM maintable LIMIT $offset, $N ORDER BY row_id
Where $offset is controlled by a scrollbar.
> A million text widgets might take some serious processing to manage.
Which, of course, is why you wouldn't create a million text widgests.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 4766
***************************************
