RE: FORMs and GET

Also note that most server-side processors including all the popular
CGI libraries for the various popular languages 
will deliver GET and POST data in a uniform manner, i.e. it's usually
a safe bet to POST data to something that looks like it will only
accept a GET.
Micah Dubinko writes:
 > For forms, the main advantage of GET is that it's currently deployed on a
 > zillion browsers and everyone understands how it works.
 > 
 > The main disadvantage of GET is that it's currently deployed on a zillion
 > browsers and everyone understands how it works...
 > 
 > In other words, changing it can be a minefield. But compatability is good,
 > and should at a minimum hold ground with what's out there.
 > 
 > Your HTML sample:
 > <body>
 >   <form action="/search" method="get" name="f">
 >     <input name="q" value="">
 >     <input type="submit" value="Google Search" name="btnG">
 >   </form>
 > </body>
 > 
 > In XForms, would be:
 > 
 > <xforms:model>
 >   <xforms:submitInfo id="f" action="/search" method="get"
 > mediaType="application/x-www-form-urlencoded"/>
 > </xforms:model>
 > ...
 > <body>
 >   <xforms:input ref="q">
 >     <xforms:caption>Google Search</xforms:caption>
 >     <xforms:submitInstance ev:event="xforms:activate" submitInfo="f"/>
 >   </xforms:input>
 > </body>
 > 
 > (note: no initial instance data required. It gets synthesized)
 > (note: mediaType on <submitInfo> seems to not have a default. Hmmm.)
 > 
 > clicking the submit control would generate a URI like
 > http://www.google.com/search?q=foo
 > 
 > .micah
 > 
 > 
 > -----Original Message-----
 > From: Paul Prescod [mailto:paul@prescod.net]
 > Sent: Thursday, January 17, 2002 6:56 PM
 > To: www-forms@w3.org
 > Subject: Re: FORMs and GET
 > 
 > 
 > "Tomayko, Ryan" wrote:
 > > 
 > >...
 > > 
 > > The content-type header that specifies application/x-www-form-urlencoded
 > > isn't talking about the query part of the URL, it's talking about the
 > POST.
 > > So I don't see how this effects the GET method.
 > 
 > So how is the data encoded for a get?
 > 
 > This is probably all a misunderstanding. I'm a frequent user of a web
 > site with this code in it:
 > 
 > <form action="/search" method="get" name=f>
 > <input maxLength=256 size=55 name=q value="">
 > <input type=submit value="Google Search" name=btnG>
 > </form>
 > 
 > This code generates expects a GET of the form:
 > 
 > http://www.google.com/search?q=foo
 > 
 > Could you show me how to translate that into XForms without 
 > application/x-www-form-urlencoded (which is to be removed)?
 > 
 > Another site uses GET URLs of the form:
 > 
 > http://slashdot.org/search.pl?query=paul&op=comments&author=&topic=&section=
 > &sort=1
 > 
 > Could you show me the XForms to generate these URLs?
 > 
 > > I don't think the spec is saying the HTTP GET method will be deprecated,
 > > it's saying that you will not be able to *POST* XForms instance data using
 > > the GET method.
 > 
 > Of course not. GET is for getting. POST is posting. But there are many
 > services in the world today that use forms to generate GET requests.
 > 
 > > ....
 > > > * why advise against GET? Most forms I use today use GET with good
 > > > reason! Furthermore, deprecation is usually the step taken before
 > > > removal!
 > > 
 > > 1. Because most web servers and some browsers have limitations on the
 > length
 > > of URL's sent in a request.
 > 
 > Fine, why not document that and let people use GET when it is
 > appropriate?
 > 
 > > 2. Because trying to convert an XML document into name=value pairs is just
 > > rediculous.
 > 
 > Using an XML document is an implementation technique. If it isn't
 > compatible with meeting the existing needs of forms users then the
 > technique needs to change. I think it is compatible -- it just needs an
 > associated URL-instance element.
 > 
 > > 3. Because GET should be used to GET an initial (parameter-less)
 > > representation of a resource. If you need to post data to a resource use
 > > POST.
 > 
 > That is not how the web works. Forms generate GET HTTP requests. In fact
 > that's the default in HTML. 
 > 
 > That's how Google works. That's how Yahoo works. That's how Slashdot
 > works. That's how ebay works. That's how Amazon works. You can't
 > deprecate one of the most common uses of forms without an adequate
 > alternative!
 > 
 >  Paul Prescod

-- 
Best Regards,
--raman
------------------------------------------------------------
T. V. Raman:  PhD (Cornell University)
IBM Research: Human Language Technologies
              Conversational And Multimodal WWW Standards
Phone:        1 (408) 927 2608
Fax:        1 (408) 927 3012
Email:        tvraman@us.ibm.com
WWW:      http://www.cs.cornell.edu/home/raman
PGP:          http://emacspeak.sf.net/raman.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120

Received on Friday, 18 January 2002 17:37:49 UTC