Re: Why is parsing your own form data a bad idea?

[Brian Gerard]

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

  /~~\
 | Brian GerardI'm sorry, are the voices  |
 | First initial + 'lists' in my head bothering you?  |
 | at technobrat dot com  |
  \__/

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Dan Muey]

> 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
- it's platform independant
- can still create the hashes you want (for whatever reason you need that, why 
would you btw?)

If you do some home brewed parsing (Like we did back in the day)
It ends up:
- Breaks easily
- May need implemented differently on different servers
- Hard to maintain
- Recreating the wheel over and over and over.
- Not portable
- can create the hashes you want but how do you know you're getting the actual 
form input or some butchery of improperly encoded/unencoded

That's a just a little input, I'm sure there's lots more than that but I'm busy.

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?

Dmuey

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Wiggins d Anconia]

> > 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
>   - it's platform independant
>   - can still create the hashes you want (for whatever reason you need
that, why would you btw?)
> 
> If you do some home brewed parsing (Like we did back in the day)
> It ends up:
>   - Breaks easily
>   - May need implemented differently on different servers
>   - Hard to maintain
>   - Recreating the wheel over and over and over.
>   - Not portable
>   - can create the hashes you want but how do you know you're getting
the actual form input or some butchery of improperly encoded/unencoded
> 
> That's a just a little input, I'm sure there's lots more than that but
I'm busy.
> 
> 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?
> 

All of what Dan said is correct and very good reasons, but the proof
lies in the code. Crank open the CGI.pm's source and look at it
yourself, it is the best indication of why you shouldn't. If you think
you would have thought of every little possible contingency etc. that is
wrapped up in that code then by all means do it yourself

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 HTTP request
which is why CGI.pm doesn't have (at least I don' think) a way to pull
both sets of data.  So the real answer is don't do it that way as it is
a poor design issue, however, not all design issues can be fixed, so to
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... 

But I am guessing

http://danconia.org



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Bob Showalter]

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: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

[Phil Schaechter]

> 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 own.  I've never used CGI.pm, but written numerous programs 
"by hand" which have served me well over the years.

I get exactly the feature set I want, operating exactly how I expect it to.  
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.

-Phil

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Dan Anderson]

> 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 they use their own
parsers for form data.  So I got so far with my own creation and am
wondering if it should be given the axe or continued.

-Dan

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Dan Anderson]

> 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]

Re: Why is parsing your own form data a bad idea?

[Jeff 'japhy' Pinyan]

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
possible).  Otherwise, determine the CGI method, and put them in the
correct hash.

  use CGI qw( param request_method );
  our (%GET, %POST);

  {
my %hash;
for (param) {
  my @values = param $_;
  $hash{$_} = (@values > 1) : [EMAIL PROTECTED] : $values[0];
}
(request_method() eq 'GET' ? *GET : *POST) = \%hash;
  }

>This seems kind of silly.  Can anyone explain to me why this is?

Do you know how hard it is to do it RIGHT?  Do you know how to parse file
uploads?  And do all the other stuff correctly?

-- 
Jeff "japhy" Pinyan  [EMAIL PROTECTED]  http://www.pobox.com/~japhy/
RPI Acacia brother #734   http://www.perlmonks.org/   http://www.cpan.org/
 what does y/// stand for?   why, yansliterate of course.
[  I'm looking for programming work.  If you like my work, let me know.  ]


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Jeff 'japhy' Pinyan]

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-standard HTTP request
>which is why CGI.pm doesn't have (at least I don' think) a way to pull

Incorrect.  The 'url_param' does it.  Look for "MIXING POST AND URL
PARAMETERS".

-- 
Jeff "japhy" Pinyan  [EMAIL PROTECTED]  http://www.pobox.com/~japhy/
RPI Acacia brother #734   http://www.perlmonks.org/   http://www.cpan.org/
 what does y/// stand for?   why, yansliterate of course.
[  I'm looking for programming work.  If you like my work, let me know.  ]


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Dan Muey]

> 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 PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

[Phil Schaechter]

> > > 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 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.

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 course, there is not a way to solve the issue 
in-spec).   *IF* (please notice the IF) your choice comes down to a 
convoluted solution with CGI.pm, or just snagging GET and POST on your own, 
my position is to do it cleanly, and on your own.

-Phil

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

[Wiggins d'Anconia]

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 you are forming a non-standard HTTP request
which is why CGI.pm doesn't have (at least I don' think) a way to pull


Incorrect.  The 'url_param' does it.  Look for "MIXING POST AND URL
PARAMETERS".
Standing corrected. Perl and its various modules rule, and never cease 
to amaze me...

http://danconia.org

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Tore Aursand]

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 unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

[R. Joseph Newton]

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 readability of Perl code.  I can't think of 
anywhere that you would want
to actually code a GET, since it is the default mode for browser requests.  It should 
not be used for CGI, though
for reasons that have already been stated.  The POST belongs in your HTML, not in your 
Perl code.  Your variable
names should reflect the subject matter they are dealing with, not nuts-and-bolts 
technical detail.

>  That and I am learning
> from the O'Reilly book CGI Programming With Perl and they use their own
> parsers for form data.  So I got so far with my own creation and am
> wondering if it should be given the axe or continued.

If it's production code, give it the axe.  Your customers deserve better 
dependability.  If you are studying cause
and effect in programming, then all means continue your experiments in hand-rolling, 
being ready to discard your
prototypes oce you have learned enough from them.

> -Dan

What is it you are trying to do?  Please answer in real-world terms.

Joseph


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

[R. Joseph Newton]

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 HTTP request
> which is why CGI.pm doesn't have (at least I don' think) a way to pull
> both sets of data.

My guess is that he really meant either, but that is just a guess also.  I think
it better to ensure that CGI is called only with POST requests.  Of course, if
that can't be helped, then CGI.pm will quite happily put the values gleaned
through the channel appropriate to the request method into the same hash,
returnable using the Vars method of the object.

> So the real answer is don't do it that way as it is
> a poor design issue, however, not all design issues can be fixed, so to
> 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...
>
> But I am guessing
>
> http://danconia.org
>
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Tore Aursand]

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.

This might not justify as "hacking" the CGI.pm, but once I had to do
something really special related to session handling.  The solution wasn't
to hack, change or write my own CGI handling module, but simply subclass
the original CGI.pm.


-- 
Tore Aursand <[EMAIL PROTECTED]>


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Jenda Krynicky]

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.

There is one. If /s?he/ is using CGI::Lite instead ;-)

Jenda
= [EMAIL PROTECTED] === http://Jenda.Krynicky.cz =
When it comes to wine, women and song, wizards are allowed 
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Dan Muey]

> 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.
> 
> This might not justify as "hacking" the CGI.pm, but once I 
> had to do something really special related to session 
> handling.  The solution wasn't to hack, change or write my 
> own CGI handling module, but simply subclass the original CGI.pm.

So that was basically taking input and doing something specific with it right?
The OP was simply parsing form data to do whatever with it. Whether that is 
printing it out, emailing it, putting in a database, or doing some special 
session handling, they never said so it's all still the same, close but no cigar :)

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Dan Muey]

> > 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 course, there is not a way to solve 
> the issue 
> in-spec).   *IF* (please notice the IF) your choice comes down to a 
> convoluted solution with CGI.pm, or just snagging GET and 
  ^^ 
Do you even know what this means?

How is 

use CGI qw(param);
my $name = param('name');

More convoluted than a forty line monstrosity that won't be 
reusable and probably won't cover all conceivable issues (like file uploading for 
instance)

You could say CGI is convoluted in the sense that it is intricate and complex, 
but it has to be for what it does is intricate and complex. However if you 
simply need to handle input just import param().

But your method is more convoluted in the negative sense that it is inticate 
and complex in a bulky hard to deal with manner.

Do what you want but I think everyone here is tryign to save you a massive headache.

*And* if you do it homebrew style then to reuse it, which you probably will, 
you still have to make it portable somehow. And if you need help with why 
something isn't working you'll do this :

[examle]
you> My code doesn't work:

you> &ParseMonkey;
you> for(keys %POST) { print; }

you> It doesn't print anythign! 

What the heck is ParseMonkey ?
Are you using strict; ??
Try this and see if it works:
 use CGI qw(param);
 for(param()) { print; }

[/example]



> POST on your own, 
> my position is to do it cleanly, and on your own.
  ^^^
On your own is not cleanly, again how is 
use CGI qw(param);
...
Messier than tons of lines of code that will likely have problems.
And besides file uploads, how do plan on handling menus or checkboxes that have 
multiple values?
 You say: BUT I SAID **IF** I have a situation that needs special ." Yes but what 
**IF**
You ever need to expand it, it will much harder to do later.

Do what you want but doing it home brew is a pretty bad idea.

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Tore Aursand]

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 valid, though;  Why do one want to use CGI::Lite instead
of CGI.pm?  Is it better?  No.  Is it safer?  No.  Is it faster?  No.  Is
it more widely used?  No.  Does it come with the Perl distribution?  No.


-- 
Tore Aursand <[EMAIL PROTECTED]>


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

[drieux]

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 that, forgive me for showing up late for this, but
allow me to argue the counter point if I may. Jenda, as usual
has a bit of tongue in cheek worth being enjoyed! But the
real 'argument' if one wishes to make it is
	getting one's head around how CGI.pm actually does it's voodoo

Folks really should pull it up with say

	perldoc -m CGI

and read the comment bars, whinings, complainings, and general
technical kvetchings. Folks really will get a much better feel
for what is going on in that space, Lincoln D. Stein, and
the freaks supporting the CGI code line have done some serious
Grand Master FunkaDelik coding to keep it alive and practical.
So let us therefore assume that folks who start out as 'beginners'
have some desire to become our replacements and start maintaining
the code lines for the Next Cool Techno Wave! And not merely be
the simple typists of text for ever. So we need to help them
understand both sides of the dark horror. The 'traditionalist'
position of 'just use the stock modules', as well as the more
'experimentalist' approach of 'hey, it IS going to hurt for a
while, and you will ENJOY the CGI module more once you survive
your folly...' since, well, as the CGI module itself notes,
there were a few things that should have started out other ways
but, well, we were all a lot younger back then.
p2: The logical extension of course is that 'parsing form data'
is a reasonably good place to step into the basics of Regular Expression
mastery, and how that Voodoo Works, while also getting one's head
around what IS required in Forms, what is cooler in Forms, and
what is SUCH a bad idea.
So the real question is not whether parsing one's own is 'good or bad'
but 'what is it that the OP is really working on'.




ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Dan Muey]

> > 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 faster?  No.  Is it more widely used?  No. 
>  Does it come with the Perl distribution?  No.

Didn't you see the ;-) ? It's a joke, ha ha ha :)
> 
> 
> -- 
> Tore Aursand <[EMAIL PROTECTED]>

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[NYIMI Jose (BMB)]

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 than HTML.
Such clients can be palm top computers, mobile phones or other device that enables 
client access.

While there is no hindrance developping differents web components that would generate 
different presentation format, this solution is costly because it requires additional 
developement of web component for each distinct client type.
These web component also contains very similar logic - they different only in the way 
they present data - which introduces maintenance problems.

Rather than generating HTML pages on the web component tier (CGI.pm), we can generate 
XML.
HTML pages contain information on how to present the data to the web browser.
XML, on the other hand, simply describes the semantics of the data - it does not say 
anything about the preseentation.

Afterwards, such XML has to be transformed to a presentation appropriate for the 
client. This can be HTML for web browser, WML for WAP devices or any other appropriate 
format.

That's here technology like XSLT (eXtensible StyleSheet Language for Transformation) 
gets into the scene.
XSLT engine will tranform the XML to presentation format of your client.

There are several XML and XSLT modules from CPAN that can help achiving aforementioned 
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 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 valid, though;  Why do one want to use CGI::Lite instead of CGI.pm?  
Is it better?  No.  Is it safer?  No.  Is it faster?  No.  Is it more widely used?  
No.  Does it come with the Perl distribution?  No.


-- 
Tore Aursand <[EMAIL PROTECTED]>


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



 DISCLAIMER 

"This e-mail and any attachment thereto may contain information which is confidential 
and/or protected by intellectual property rights and are intended for the sole use of 
the recipient(s) named above. 
Any use of the information contained herein (including, but not limited to, total or 
partial reproduction, communication or distribution in any form) by other persons than 
the designated recipient(s) is prohibited. 
If you have received this e-mail in error, please notify the sender either by 
telephone or by e-mail and delete the material from any computer".

Thank you for your cooperation.

For further information about Proximus mobile phone services please see our website at 
http://www.proximus.be or refer to any Proximus agent.


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Jenda Krynicky]

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 lot of CGI::*
> modules out there.

Yep, two of them mine.

> My point is still valid, though;  Why do one want to use CGI::Lite
> instead of CGI.pm?  Is it better?  No.  

Define better.

> Is it safer?  No.  

Can't say. I guess not. But you can't be safer than safe, can you ;-)

> Is it faster?  No.  

Oh yeah.
See http://www.perlmonks.org/index.pl?node_id=145790

> Is it more widely used?  No.
> Does it come with the Perl distribution?  No.

Jenda
= [EMAIL PROTECTED] === http://Jenda.Krynicky.cz =
When it comes to wine, women and song, wizards are allowed 
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Dan Muey]

> 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 self brew thing is going to parse and handle XML then also?
That would be a learning experience.

CGI also does not make coffee,
You would need a coffee maker of some sort to do that.

The fact still remains, it's a bad idea to parse your own input, 
whether it's html, xml, whatever - if there's a standard, portable, 
safe, etc way to do it.

My last 0.02, this is getting anoying. Do what you want.

> And this is not a joke :-)

Yes it is! :)

> 
> My 0.02
> 
> José.

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

[R. Joseph Newton]

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
> > you can't do without hacking it.
>
> This might not justify as "hacking" the CGI.pm, but once I had to do
> something really special related to session handling.  The solution wasn't
> to hack, change or write my own CGI handling module, but simply subclass
> the original CGI.pm.

Excellent idea.  It's really the core of OOPs power.  How is CGI for
subclassing?

Joseph


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

[R. Joseph Newton]

"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 than HTML.
> Such clients can be palm top computers, mobile phones or other device that enables 
> client access.

Hold it!  We are talking about CGI work and the Web.  The web is defined as the set 
links that connect html pages to each other.  For other programming or iInternet 
communication tasks, you certainly would find other functionality more
appropriate.

Joseph


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

[drieux]

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 increasing
requirements to support clients expecting other format than HTML.
Such clients can be palm top computers, mobile phones
or other device that enables client access.
Hold it!  We are talking about CGI work and the Web.  The web
is defined as the set links that connect html pages to each other.
For other programming or iInternet communication tasks, you certainly
would find other functionality more appropriate.
[..]

actually, if we want to be pedantic, CGI ( common gateway interface )
as opposed to say 'computer generated images' - is a set of 'rules'
about how a "web_server" will broker deals with other code. It will
set up certain envrionmental variables, and pass information to
that code in a given manner. It will of course 'return' anything
sent to it over STDOUT to the original caller.
When we remember that the "web_server" is merely an 'httpd' -
a daemon that knows how to 'cope' with "HTTP" as the session layer,
then one has that 'coffee break moment' that there is NOTHING in
the HTTP spec that mandates the 'content' of an HTTP message. the
fact that so many folks have become 'attached' to the idea that
it is about 'HTML' is, well, a cultural artifact and not a part
of the actual spec.
As such, it IS perfectly legitimate to use HTTP as one's session
layer, and hence to have CGI code that IS NOT about passing
HTML around. If anything that is a part of the amusement of
Jose's core position. A point that folks who view 'web services'
in the limited image of being merely about 'web browser' based
'html' technology tend to ZONE OUT.
Granted getting one's head out of the limitations of HTML as
a 'mark up language' can be hard for some folks - but it IS
something that folks need to wake up, smell the coffee, and
get on with what is IN the HTTP spec, as opposed to the
various "DOMs" for HTML/XHTML, and that CGI ( common gateway interface )
itself does NOT mandate the 'content' that the 'deal' is
brokered in between the 'httpd' and code invoked!!!
At which point, one really can decide if one wants to
use the CGI.pm module to simplify things, or whether the
parameter picking process is simpler done with one's own
tailored parser.


ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

[Wiggins d Anconia]

> 
> 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 increasing
> >> requirements to support clients expecting other format than HTML.
> >> Such clients can be palm top computers, mobile phones
> >> or other device that enables client access.
> >
> > Hold it!  We are talking about CGI work and the Web.  The web
> > is defined as the set links that connect html pages to each other.
> > For other programming or iInternet communication tasks, you certainly
> > would find other functionality more appropriate.
> [..]
> 
> actually, if we want to be pedantic, CGI ( common gateway interface )
> as opposed to say 'computer generated images' - is a set of 'rules'
> about how a "web_server" will broker deals with other code. It will
> set up certain envrionmental variables, and pass information to
> that code in a given manner. It will of course 'return' anything
> sent to it over STDOUT to the original caller.
> 
> When we remember that the "web_server" is merely an 'httpd' -
> a daemon that knows how to 'cope' with "HTTP" as the session layer,
> then one has that 'coffee break moment' that there is NOTHING in
> the HTTP spec that mandates the 'content' of an HTTP message. the
> fact that so many folks have become 'attached' to the idea that
> it is about 'HTML' is, well, a cultural artifact and not a part
> of the actual spec.
> 
> As such, it IS perfectly legitimate to use HTTP as one's session
> layer, and hence to have CGI code that IS NOT about passing
> HTML around. If anything that is a part of the amusement of
> Jose's core position. A point that folks who view 'web services'
> in the limited image of being merely about 'web browser' based
> 'html' technology tend to ZONE OUT.
> 
> Granted getting one's head out of the limitations of HTML as
> a 'mark up language' can be hard for some folks - but it IS
> something that folks need to wake up, smell the coffee, and
> get on with what is IN the HTTP spec, as opposed to the
> various "DOMs" for HTML/XHTML, and that CGI ( common gateway interface )
> itself does NOT mandate the 'content' that the 'deal' is
> brokered in between the 'httpd' and code invoked!!!
> 
> At which point, one really can decide if one wants to
> use the CGI.pm module to simplify things, or whether the
> parameter picking process is simpler done with one's own
> tailored parser.
> 

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 noses!  There is a realization to make here that some of us
have become so used to the "it just works" model of web development that
we even begin to think of things such as images that come down over that
same big pipe as actually being part of the actual page, rather than a
completely separate request/response/session!  Even if we aren't talking
about all those web service things, this is the best reminder that what
travels over HTTP need not be HTML-esque.

http://danconia.org

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

[drieux]

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 noses!
[..]

Interesting, hadn't thought about the 'image' side of the
problem. Rather I was thinking in terms of what some would
be calling 'web proxying' and/or 'distributed computing'
where we just happen to be using HTTP as the session layer
hence 'technically' the 'web_server' at the other end of
the socket connection 'could' dish up "web pages" rather
than, well, just be the 'bridge' between the HTTP Request
and the specified URI thingus, which turns out to be a
piece of Perl CGI code, that doesn't have to be god's
brightest crayon in the box, since it merely has to know
whether the 'parameters' passed to it are 'kosher' before
it invokes some code on that box...
That fiasco started out the old fashion way:

Yeah, so we just hand wave a database abstraction layer (DAL)
over there, and we chat with it using HTTP as the session layer,
then all we need is to define the syntax and semantics of the
DAL, and the web-tool will just do the majik
only to find out that, uh, no one was working on the database side
of the DAL, and well, so we hacked from the 'knows how to take
in the CGI foo' and stuff something like a DB there...
As someone once asked,

	but why didn't you use SOAP, etc, etc, etc.

and the only answer I could say was

it was not suppose to be big, complex, and/or require
the addition 'effort' that would have gone into that,
since that would have required that all of the SOAP modules
be installed...
so one hacks, one uses the freaking

	use lib "";

and makes sure one's installer plonks everything where it is
suppose to be on the 'web server' - even if it IS only a
freaking httpd droid that will never actually dish out a
web page...
As the Maxim Goes,

	start small, plan to improves.

ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

[R. Joseph Newton]

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 different type of clients.
> > >> Unfortunately CGI.pm will not fulfill the increasing
> > >> requirements to support clients expecting other format than HTML.
> > >> Such clients can be palm top computers, mobile phones
> > >> or other device that enables client access.
> > >
> > > Hold it!  We are talking about CGI work and the Web.  The web
> > > is defined as the set links that connect html pages to each other.
> > > For other programming or iInternet communication tasks, you certainly
> > > would find other functionality more appropriate.
> > [..]
> >
> > actually, if we want to be pedantic, CGI ( common gateway interface )
> > as opposed to say 'computer generated images' - is a set of 'rules'
> > about how a "web_server" will broker deals with other code. It will
> > set up certain envrionmental variables, and pass information to
> > that code in a given manner. It will of course 'return' anything
> > sent to it over STDOUT to the original caller.
>
> 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 noses!  There is a realization to make here that some of us
> have become so used to the "it just works" model of web development that
> we even begin to think of things such as images that come down over that
> same big pipe as actually being part of the actual page, rather than a
> completely separate request/response/session!  Even if we aren't talking
> about all those web service things, this is the best reminder that what
> travels over HTTP need not be HTML-esque.
>
> http://danconia.org

I'd suggest that you both rered the post I was responding to.  I wasn't
suggesting that any single MIME type or protocol should be the exclusive
concern of CGI activity.  What I am saying is that rools that can't handle
html or other standard protocols for http exchange should not dictate
standards for delivery or processing of Web content.  Let the telecoms develp
content for their own disposables.

Cell phones are great for transmitting voice, and even for storing and
managing voice messages.  Likewise, palmtops can be handy tools for the
emerency capture, in electronic form,   These are the roles for which these
instruments are ergonomically suited.  What do they have to do with processing
of serious Web-based content.?

Just because the marketing-slime of the telecom industry latch onto the work
of serious thinkers and try to bathe in the aura of illusory "progress", does
that mean we should adjust to accomodate them?  Not unless they [ie the
telecoms and the multinational belly-crawlers who finance them] are paying
me.  There is plenty of real work to be accomplished without supporting the
illusion of usefulness for products that are shoddily made and intentionall
designed to hit the landfill within a year of purchase.

If somebody wants to interact with Web content I create, they can damn well
sit down in front of a real screen.  If the folks who make those throw-away
Crickets want achannel for their toys to connect to, they can contract with me
privately, then I will start looking at solutions specialized to their
proprietary garbage.

Joseph


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

[R. Joseph Newton]

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 that very protocol right
> > under our noses!
> [..]
>
> Interesting, hadn't thought about the 'image' side of the
> problem. Rather I was thinking in terms of what some would
> be calling 'web proxying' and/or 'distributed computing'
> where we just happen to be using HTTP as the session layer
> hence 'technically' the 'web_server' at the other end of
> the socket connection 'could' dish up "web pages" rather
> than, well, just be the 'bridge' between the HTTP Request
> and the specified URI thingus, which turns out to be a
> piece of Perl CGI code, that doesn't have to be god's
> brightest crayon in the box, since it merely has to know
> whether the 'parameters' passed to it are 'kosher' before
> it invokes some code on that box...

Hmmm, these sound more interesting than feeding toys.  My point remains, though,
that this is a whole different world than standard Web-based programming.  As you
point out yourself, the connection is only incidental.  Therefore, I still don't see
why this should be an issue in the selection of tools for the handling of
traditional Web=based interactive content.

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 think that the appearance
of both is important.  I strongly agree with the design goal of XML that source
should be human-readable and clear.  I would add ergonomically sensible to the
standards.  Parsing form data, the subject of the OP, is a different matter.  CGI
does a very solid job of abstracting the details of delivery format, and rendering
the parameters to the application.  What more do you need from a CGI module?  For
other purposes, you can use other modules.

[snip -- gettin' wa-a-a-ay out there, dude!]

Joseph


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

[Paul Johnson]

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 PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is parsing your own form data a bad idea?

[drieux]

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 think that the appearance of both is important.
you will forgive me if I truncate the content here
to help refocus the discussion. I am also, well pleasantly
amused that we both agree, mostly-ish, that the CGI.pm
module has 'upside' and 'downside' issues.
p0: since this is a beginning list, it is probably best
to re-iterate that it is a great place to start! both
in terms of using the model to begin with for 'creating'
HTML content, and stepping into the Abyss of CGI.
p1: at which point one then needs to start asking the
sort of question like, "so why exactly do I want to
use this module over that module" - since there are
some really fun modules out there, including some
serious folks working on a Form Application Framework
that mostly simplifies the process, somewhat.
I strongly agree with the design goal of XML that source
should be human-readable and clear.  I would add ergonomically
sensible to the standards.
p2: Ironically of course PCDATA is also, well, an xml application,
hence 'raw ascii' also complies 8-)
Parsing form data, the subject of the OP, is a different matter.
CGI does a very solid job of abstracting the details of delivery
format, and rendering the parameters to the application.  What more
do you need from a CGI module?  For other purposes, you can use other 
modules.
[..]

p3: The OP's question, if I am correct,
cf: 
also specifically addressed the kvetch in the FAQ, which asserted:

<<"You use a standard module, probably CGI.pm. Under no
circumstances should you attempt to do so by hand!">>
and hence his step off to the horrors of what would be badly
named hashes  eg %GET and %POST - garish! yech!! tasteless
naming schema! ptewee... That we should kudgel dan for! since it is
such an affront to 'good taste'.
but structurally his idea is Kosher in challenging the 'recieved'
wisdom of the Omniscient Perl Faq! Since once one steps out there
and does the first Nightmare of something like:
...
my $request = $ENV{'REQUEST_METHOD'};
...
if( defined($request) && $request =~ m/^POST|GET|HEAD$/)
{
my $queryString = ($request eq 'POST' )?
 : $ENV{'QUERY_STRING'};

my $qs = unpack_query_string($queryString);

$page = ( ($qs && defined($qs->{dir})))?
 do_it($qs): make_localPage() ;
}else{
...
# normally I send UGLY message to browser about DISALLOWED
}
since of course POST and GET will pass the information in different
manner, and some Whiney Implementations of Browsers will want to
know that they could 'HEAD' the cgi - but of course he will want
to make emotional commitments about the rest of the basic syntax
and semantics that can be done with CGI on the else side of the
branch... { assuming that he doesn't CHEAT and create his own
set of them for 'not merely woofing HTML' forms of CGI }
So they start picking and grinning with their own 'query string 
unpacker'
like say something a la:
	#
	#
	sub unpack_query_string
	{
		my ($qstring) = @_;
		
		return unless $qstring;
		
		my $queryHash;
		
		chomp($qstring);
		my @args = split(/&/, $qstring);
		
		foreach my $thing ( @args) {
			my ($k, $v) = split(/=/, $thing);
			next unless(defined($v) && $v ne '');
			# double coverage here, requires var=val structure
			$k =~ s/\+/ /g; $k =~ s/%(..)/pack("c",hex($1))/ge;
			$v =~ s/\+/ /g; $v =~ s/%(..)/pack("c",hex($1))/ge;
			$v =~ s/\s+$//;
			$v =~ s/^\s+//;
			$queryHash->{$k} = $v;
		}
	
		$queryHash;
	
	} # end of unpack_query_string

and yes, yes, yes, that way does lead to the problems about
how to make the right types of choices should a form want
to pass back a list var1=bob&var1=sally&var1=orthodoxy, but
that too will be something that they will think about and
implement a unpack_query_string_with_dupes() that they will
use for the times when they notice
Friggolating, what was I thinking about in allowing the
Primate to Select Multiple things, OxygenSuckingCarbonBasedLifeForms
that merely Poke, Poke at the Pretty GUI interface
I mean we all make that mistake more than a few times in the process...

"lovely web application, but we want you to add just this
little check box option on"
But do we SHOOT the marketing DROIDS at that tyme? Do We Pour
coffee down their fronts and watch their little circuits fry
{ oh, sorry, wrong rant. }
Clearly if we allow beginners to question the Recieved Truths,
and start wandering off t

RE: Why is parsing your own form data a bad idea?

[Tore Aursand]

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't say. I guess not. But you can't be safer than safe, can you ;-)

With CGI.pm you are sure that millions of other servers are using it, and
thereby it's been tested more thoroughly.

>> 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.


-- 
Tore Aursand <[EMAIL PROTECTED]>


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Why is parsing your own form data a bad idea?

[Dan Muey]

> >> 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 all the same priciples apply to mod_perl 
run scripts as well as non mod_perl. Except now you have to think 
about how your homebrewed code handles the memory stuff mod_perl.

So if any thing a mod_perl envcirnmet makes home brewed code even 
more likely to be troublesome.

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]