W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

Re: URLQuery / FormData

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 9 Sep 2013 09:49:14 -0700
Message-ID: <CAAWBYDBF9PrWDGtWAuLx4KBF37E7dBaZJrdL-QhKHZsKn7hsVw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On Mon, Sep 9, 2013 at 4:30 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> We had a discussion here once before I think about a good
> representation for an ordered list of name/value pairs (i.e. allows
> duplicate names). In particular this is what <form> represents and
> therefore quite important.
> http://url.spec.whatwg.org/#interface-urlquery has an API, but looking
> over it now it's not really consistent in how get/set/delete works.
> My current thinking is to update URLQuery as follows:
> * get(name) -- always returns an array, with ES6 destructering this
> should be fine
> * append(name, value) -- always appends to the end
> * delete(name) -- always removes all
> * has(name) -- same as now
> I'll leave out set() for now.

Did you forget the reasoning for the current design?  It was quite
intentional - it was meant to create a MultiMap, which acts like a
normal Map if you interact with it naively using Map methods, but
which can also be interacted with (via getAll() and append()) in a way
that supports multiple values per key.

This design was settled on precisely *because* of the fact that most
of the time people only put a single value per key in their urls, so
this avoided having to layer on the mental tax of dealing with arrays
when it wasn't otherwise necessary.  It's an improvement over, say,
Python's cgi API, which returns *either* an item or a list (or an
exception, if the key didn't exist) from the naive retrieval method,
but has a way to force a list to be returned.

In fact, now it should probably be a [MapClass] in WebIDL, with some
of its methods overridden.

> Since it's a list I don't think item count should be called size, but
> rather length. However, maybe we don't need that for now either.

Same thing there - Maps have .size, so MultiMaps should have .size as well.

The fact that it's described as a list of key/value pairs has no
bearing here - it's not a list interface, it's a map interface.  Maps
are also described as a key/value pair list in the ES spec.

> The object should also support iteration. Waiting for that to get
> implemented in browsers and become more stable.

If it's a [MapClass], this is taken care of already.

Received on Monday, 9 September 2013 16:50:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC