Re: A URL API

I've removed the searchParameters attribute from the URL interface for
the time being.  We can consider adding it back at a later time.

Adam


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