Re: A URL API

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:22:11 UTC