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

Re: URLQuery / FormData

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 10 Sep 2013 02:39:17 +0200
Message-ID: <CA+c2ei9PvJChKjRG61FH29VMJFYr-XHS31a4Wy7stkpOsM0ALw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On Tue, Sep 10, 2013 at 1:15 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Mon, Sep 9, 2013 at 11:31 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> obj.get(name)
>> returning the first value.
>> obj.getAll(name) or obj.getMulti(name)
>> returning an array.
> The problem with this is that then get and delete are no longer
> describing similar kinds of operations. get only operates on the first
> matching value. delete operates on all matching values.

I don't really think there's a mismatch.

A consumer can either operate on the data as simple name/value map. In
which case he/she would use the obj.get and obj.delete functions. Or
the consumer that wants can support multiple values for each name, in
which case he/she would use obj.getAll/obj.delete.

In either case the function pairs expose consistent behavior.

By allowing consumers to treat the query data as a simple map we
actually reduce the risk of bugs due to multiple values being passed
to a page that didn't expect it. Instead additional values are

However consumers that does want to support multiple values get a
perfectly consistent and sensible API for handling that.

Same thing if we add .set to the mix. get/delete/set create a
consistent API which as a bonus reuses the same API as Map.

Likewise getAll/delete/set/append expose a consistent API for handling
multiple values. I agree that it's not a perfect API for handling
multi-values since it doesn't support things like "replace the second
value" or "delete the second value". However that can be added later
if really needed. I'd tend to guess that the use cases are rare enough
that it's fine to leave out.

>> I can live with names other than 'set' if that is the controversial
>> bit. I don't understand why there's all this resistance to creating an
>> API which is compatible with existing JS APIs though? The DOM going
>> its own way and using a "not invented here" approach has always seemed
>> like a bad thing to me.
> I don't understand what you mean here.

We have gotten a lot of critisism over the years for creating APIs
that doesn't reuse existing JS infrastructure. And rightfully so. It's
annoying for authors to have to learn a new variations of interacting
with the APIs that they are using.

>> As far as I can tell it should be possible to make this object fully
>> compatible with a Map.
> It seems fundamentally incompatible with a Map. E.g. a Map does not
> support checkboxes.

For consumers that want simple name/value mappings it is fully
compatible with Map. As an added bonus it is compatible with Map even
when passed multiple values for a single name.

For consumers that want to deal with multiple values it is of course
impossible to make it compatible with Map.

/ Jonas
Received on Tuesday, 10 September 2013 00:40:15 UTC

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