W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010


From: Adam Barth <w3c@adambarth.com>
Date: Fri, 17 Sep 2010 17:43:15 -0700
Message-ID: <AANLkTimOUFn=e3dG39kMT7T_KiDqgXEyFJ2Vx_X71zVG@mail.gmail.com>
To: Garrett Smith <dhtmlkitchen@gmail.com>
Cc: Maciej Stachowiak <mjs@apple.com>, Darin Fisher <darin@chromium.org>, Julian Reschke <julian.reschke@gmx.de>, Anne van Kesteren <annevk@opera.com>, Boris Zbarsky <bzbarsky@mit.edu>, WebApps WG <public-webapps@w3.org>
I've removed the searchParameters attribute from the URL interface for
the time being.  We can consider adding it back at a later time.


On Fri, Sep 17, 2010 at 5:21 PM, Garrett Smith <dhtmlkitchen@gmail.com> wrote:
> On 9/17/10, Adam Barth <w3c@adambarth.com> wrote:
>> On Fri, Sep 17, 2010 at 2:39 PM, Garrett Smith <dhtmlkitchen@gmail.com>
>> wrote:
>>> On 9/17/10, Adam Barth <w3c@adambarth.com> wrote:
>>>> On Fri, Sep 17, 2010 at 11:57 AM, Garrett Smith <dhtmlkitchen@gmail.com>
>>>> wrote:
>>>>> Where is Dictionary defined?
>>>> It might not be defined yet.
>>> You don't know if it is defined or not? Makes no sense at all.
>> That's correct.  [...]
> OK - glad we're on the same page :-D
>>> If, for each parameter, the dictionary gets a key entry with the value
>>> corresponding to the parameter name, then what is the value associated
>>> with that key. Referring again to the xample, what would be the value
>>> of x.searchParameters.title -- an Array?
>> The value would be a string, such as "foo" or "bar".  In the example
>> you gave, there are two parameters with the name title.  The
>> specification will say which of the two values will show up in the
>> dictionary, but I haven't studied the question of which one yet.
> That's just awful.
> A URI can have a parameter that appears more than once and it is very
> common case where they do. That is how checkboxes work -- multiple
> elements with same name, but different values. Same deal with
> select-multiple.
> [...]
> That means I can't have "valueOf" as a query param. Or "__proto__",
> "toSource", etc.
>> Rather than invent a new dictionary type, I think it make sense to use
>> the native one in the language (which in JavaScript is called Object),
>> which connects up with why modifying the dictionary doesn't mutate the
>> underlying URL.
> Then say what you mean in that document. Object is not "Dictionary" If
> you mean Object, say it there.
> And I disagree. I think Dictionary is better. And while I'm at it,
> I'll make it LiveDictionary and borrow from Storage so it can use
> LiveDictionary too.
> LiveDictionary {
>  readonly attribute unsigned long length;
>  DOMString key(in unsigned long index);
>  any getItem(in DOMString key);
>  void setItem(in DOMString key, in any value);
>  void removeItem(in DOMString key);
>  void clear();
> }
> Even better than Storage. I've omitted the WebIDL's nonstandard, ECMA
> syntax extensions of "getter" which has no place being defined in
> WebIDL and should not be used until it is specified by ECMA (which may
> be never)).
>>> Working with parameter values can be a tricky if, say, the the program
>>> wants to remove one value for title and keep another. If URI has a
>>> getParameterMap then it should either be live or it should have a
>>> setParameterMap method. The one way API makes no sense.
>> I don't think we need to tackle that problem in the first version.
>> HTML has a very nice way of constructing URLs with query parameters
>> called the form element.
> So what? Your advice is for the client of the API to create a FORM
> element, create INPUT elements, then what?
> I'm not following the usage pattern.
> Garrett
Received on Saturday, 18 September 2010 00:44:26 UTC

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