RE: Why is parsing your own form data a bad idea?
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]
RE: Why is parsing your own form data a bad idea?
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?
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?
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?
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 place_relative_to_here; 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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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/ stu what does y/// stand for? tenderpuss 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?
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?
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?
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?
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?
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?
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]
