And the clouds parted, and Dan Anderson said...
>
> This seems kind of silly. Can anyone explain to me why this is?
>
Beats me. I've been rolling my own cgi-handlers since perl4 with no
discernable ill effects. :) Let me know if you want some sample code.
Brian
/~
> This seems kind of silly. Can anyone explain to me why this is?
Because if you do :
use CGI qw(param);
- It will work
- Implemented the same in every script in every server
- people will understand what you're doing
- it's reusable over and over and over
> > This seems kind of silly. Can anyone explain to me why this is?
>
> Because if you do :
>
> use CGI qw(param);
> - It will work
> - Implemented the same in every script in every server
> - people will understand what you're doing
> - it's reusable over and over and
Dan Anderson wrote:
> There doesn't seem to be what I want in CGI.pm. (I want to
> create a %GET and %POST hash of the form $HASH{NAME} = VALUE).
Look at perldoc CGI under "FETCHING THE PARAMETER LIST AS A HASH"
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAI
> hack around it I suspect you could pull out the POST data, then grab the
> actual full URL then pass it back through CGI's private methods to grab
> the data that is there also and combine the two...
>
Or, the OP can do what I have been doing for years with no ill effects, and
simply write your
> If you explain why you need the %POST and %GET hashes specifically maybe we can help
> you do it the best way.
> So whjat are you trying to accomplish with those hashes?
Well it's mostly just readability of the code. That and I am learning
from the O'Reilly book CGI Programming With Perl and t
> Look at perldoc CGI under "FETCHING THE PARAMETER LIST AS A HASH"
Hmmm...seems like I was looking in the wrong place of the
documentation. Thanks.
-Dan
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Nov 5, Dan Anderson said:
>There doesn't seem to be what I want in CGI.pm. (I want to create a
>%GET and %POST hash of the form $HASH{NAME} = VALUE).
So make them yourself. You can use param() and url_param() to get POST
and GET parameters if BOTH have been used in the same program (this is
On Nov 5, Wiggins d Anconia said:
>I suspect your comment about wanting "%POST and %GET" has more to do
>with the 'and' than the values on either side. If my assumption is
>correct and you are passing *both* values in the content body and in the
>url header then I believe you are forming a non-sta
> If it comes to the point where you need to "hack around"
> CGI.pm, I'd say go
> with your original inclination to just do it yourself.
Give me one example when you'd need to hack CGI.pm to handle
input that you can't do without hacking it.
>
> -Phil
--
To unsubscribe, e-mail: [EMAIL PROTEC
> > > hack around it I suspect you could pull out the POST data, then grab the
> > > actual full URL then pass it back through CGI's private methods to grab
> > > the data that is there also and combine the two...
> >
> > If it comes to the point where you need to "hack around"
> > CGI.pm, I'd say
Jeff 'japhy' Pinyan wrote:
On Nov 5, Wiggins d Anconia said:
I suspect your comment about wanting "%POST and %GET" has more to do
with the 'and' than the values on either side. If my assumption is
correct and you are passing *both* values in the content body and in the
url header then I believe y
On Wed, 05 Nov 2003 17:22:10 -0500, Dan Anderson wrote:
> So I got so far with my own creation and am wondering if it should be
> given the axe or continued.
Axe it. Really. There is absolutely _no_ reason why one shouldn't use
the CGI.pm module.
--
Tore Aursand <[EMAIL PROTECTED]>
--
To u
Dan Anderson wrote:
> > If you explain why you need the %POST and %GET hashes specifically maybe we can
> > help you do it the best way.
> > So whjat are you trying to accomplish with those hashes?
>
> Well it's mostly just readability of the code.
GET and POST do not in any way add to the reada
Wiggins d Anconia wrote:
> I suspect your comment about wanting "%POST and %GET" has more to do
> with the 'and' than the values on either side. If my assumption is
> correct and you are passing *both* values in the content body and in the
> url header then I believe you are forming a non-standard
On Wed, 05 Nov 2003 17:22:43 -0600, Dan Muey wrote:
>> If it comes to the point where you need to "hack around" CGI.pm, I'd
>> say go with your original inclination to just do it yourself.
> Give me one example when you'd need to hack CGI.pm to handle input that
> you can't do without hacking it.
From: Tore Aursand <[EMAIL PROTECTED]>
> On Wed, 05 Nov 2003 17:22:10 -0500, Dan Anderson wrote:
> > So I got so far with my own creation and am wondering if it should
> > be given the axe or continued.
>
> Axe it. Really. There is absolutely _no_ reason why one shouldn't
> use the CGI.pm module
> On Wed, 05 Nov 2003 17:22:43 -0600, Dan Muey wrote:
> >> If it comes to the point where you need to "hack around"
> CGI.pm, I'd
> >> say go with your original inclination to just do it yourself.
>
> > Give me one example when you'd need to hack CGI.pm to handle input
> > that you can't do wit
> > Give me one example when you'd need to hack CGI.pm to handle input
> > that you can't do without hacking it.
>
> Are you asking me? I said, "if it comes to the point that..."
>
> However, my example would be, as someone previously
> mentioned, doing something
> out-of-spec (assuming of co
On Thu, 06 Nov 2003 13:21:15 +0100, Jenda Krynicky wrote:
>> There is absolutely _no_ reason why one shouldn't use the CGI.pm
>> module.
> There is one. If /s?he/ is using CGI::Lite instead ;-)
In that case, there are many reasons. There are a lot of CGI::* modules
out there.
My point is still
On Thursday, Nov 6, 2003, at 09:13 US/Pacific, Tore Aursand wrote:
[..]
My point is still valid, though;
p0: there is a cgi beginner's mailing list <[EMAIL PROTECTED]>
that is devoted to the specific fun/horror of cgi coding in perl
for those interested in raising the general issues.
p1: barring th
> > There is one. If /s?he/ is using CGI::Lite instead ;-)
>
> In that case, there are many reasons. There are a lot of
> CGI::* modules out there.
>
> My point is still valid, though; Why do one want to use
> CGI::Lite instead of CGI.pm? Is it better? No. Is it
> safer? No. Is it faste
ioned
requiremnts, CGI.pm will not ...
And this is not a joke :-)
My 0.02
José.
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Tore Aursand
Sent: Thursday, November 06, 2003 6:14 PM
To: [EMAIL PROTECTED]
Subject: RE: Why is parsing your own form data a bad idea?
On Th
From: Tore Aursand <[EMAIL PROTECTED]>
> On Thu, 06 Nov 2003 13:21:15 +0100, Jenda Krynicky wrote:
> >> There is absolutely _no_ reason why one shouldn't use the CGI.pm
> >> module.
>
> > There is one. If /s?he/ is using CGI::Lite instead ;-)
>
> In that case, there are many reasons. There are a
> There are several XML and XSLT modules from CPAN that can
> help achiving aforementioned requiremnts, CGI.pm will not ...
>
The OP was interested in parsing form data, apparently from html.
Yes CGI does not parse/handle XML,
You would need an XML handling type module to do that.
And this se
Tore Aursand wrote:
> On Wed, 05 Nov 2003 17:22:43 -0600, Dan Muey wrote:
> >> If it comes to the point where you need to "hack around" CGI.pm, I'd
> >> say go with your original inclination to just do it yourself.
>
> > Give me one example when you'd need to hack CGI.pm to handle input that
> > y
"NYIMI Jose (BMB)" wrote:
> One reason to not use CGI.pm:
>
> An important concern today in the integration architecture is to provide a means to
> support different type of clients.
> Unfortunately CGI.pm will not fulfill the increasing requirements to support clients
> expecting other format t
On Thursday, Nov 6, 2003, at 18:55 US/Pacific, R. Joseph Newton wrote:
"NYIMI Jose (BMB)" wrote:
One reason to not use CGI.pm:
An important concern today in the integration architecture
is to provide a means to support different type of clients.
Unfortunately CGI.pm will not fulfill the increasin
>
> On Thursday, Nov 6, 2003, at 18:55 US/Pacific, R. Joseph Newton wrote:
> > "NYIMI Jose (BMB)" wrote:
> >
> >> One reason to not use CGI.pm:
> >>
> >> An important concern today in the integration architecture
> >> is to provide a means to support different type of clients.
> >> Unfortunately
On Friday, Nov 7, 2003, at 10:11 US/Pacific, Wiggins d Anconia wrote:
[..]
Thank you for putting this so eloquently, to back it up with the most
simple example of all though remember images, that a majority of
web
sites use these days, are distributed over that very protocol right
under our no
Wiggins d Anconia wrote:
> >
> > On Thursday, Nov 6, 2003, at 18:55 US/Pacific, R. Joseph Newton wrote:
> > > "NYIMI Jose (BMB)" wrote:
> > >
> > >> One reason to not use CGI.pm:
> > >>
> > >> An important concern today in the integration architecture
> > >> is to provide a means to support differ
drieux wrote:
> On Friday, Nov 7, 2003, at 10:11 US/Pacific, Wiggins d Anconia wrote:
> [..]
> > Thank you for putting this so eloquently, to back it up with the most
> > simple example of all though remember images, that a majority of
> > web
> > sites use these days, are distributed over tha
On Thu, Nov 06, 2003 at 06:46:18PM -0800, R. Joseph Newton wrote:
> Excellent idea. It's really the core of OOPs power. How is CGI for
> subclassing?
Take a look at CGI::Pretty for an example.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
--
To unsubscribe, e-mail: [EMAIL PROTECTE
On Friday, Nov 7, 2003, at 11:42 US/Pacific, R. Joseph Newton wrote:
[..]
Perl has many APIs, for many purposes. I personally don't like using
CGI.pm for generating Web conent. This I do by hand, checking the
generated
html source and its rendered appearance throughout the process, because
I thi
On Thu, 06 Nov 2003 19:37:51 +0100, Jenda Krynicky wrote:
>> My point is still valid, though; Why do one want to use CGI::Lite
>> instead of CGI.pm? Is it better? No.
> Define better.
Well. Actually I guess it's a combination of all the other factors I
listed. :-)
>> Is it safer? No.
> Can
> >> Is it faster? No.
>
> > Oh yeah.
> > See http://www.perlmonks.org/index.pl?node_id=145790
>
> Neither of the benchmarks on that address uses a real-life
> mod_perl scenario as basis for the testing.
Nobody said anything about mod_perl!! More and more 'situations'
keep coming up. Anyway
36 matches
Mail list logo
