Re: Why is parsing your own form data a bad idea?
From: Drieux (drieux_at_wetware.com)
Date: 11/07/03
- Next message: Drieux: "Re: fork() and Jabber connection handles"
- Previous message: Drieux: "Re: Using Perl with PC Anywhere?"
- In reply to: R. Joseph Newton: "Re: Why is parsing your own form data a bad idea?"
- Next in thread: Wiggins D Anconia: "Re: Why is parsing your own form data a bad idea?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 7 Nov 2003 08:52:44 -0800 To: begin begin <beginners@perl.org>
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
---
- Next message: Drieux: "Re: fork() and Jabber connection handles"
- Previous message: Drieux: "Re: Using Perl with PC Anywhere?"
- In reply to: R. Joseph Newton: "Re: Why is parsing your own form data a bad idea?"
- Next in thread: Wiggins D Anconia: "Re: Why is parsing your own form data a bad idea?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|