- From: <tvraman@almaden.ibm.com>
- Date: Fri, 18 Jan 2002 14:36:31 -0800
- To: Micah Dubinko <MDubinko@cardiff.com>
- Cc: "'Paul Prescod'" <paul@prescod.net>, www-forms@w3.org
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=§ion= > &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