RE: FORMs and GET

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

Received on Friday, 18 January 2002 16:40:12 UTC