Re: A URL API
On Fri, Sep 17, 2010 at 11:05 AM, Adam Barth w...@adambarth.com wrote: On Fri, Sep 17, 2010 at 10:27 AM, Adam Barth w...@adambarth.com wrote: On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisher da...@chromium.org wrote: On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke julian.resc...@gmx.de wrote: That sounds good to me. In general I think it would be great if there were standard APIs for URI/IRI construction, parsing and resolution... Yes, that sounds pretty good to me too. This has annoyed me for a while too. I'll write up a spec. Here's a sketch: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en It appears [1] that there are sites out there which use URL as a property already, which isn't very surprising. The good news is that if we ensure that the property is replacable then it seems like things will work. So all that should be needed is the right WebIDL magic, or right prose, to define that the URL property is replaceable. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=617296 / Jonas
Re: A URL API
On Mon, Sep 20, 2010 at 9:27 AM, Adam Barth w...@adambarth.com wrote: On Sun, Sep 19, 2010 at 10:48 PM, Devdatta Akhawe dev.akh...@gmail.com wrote: 1) There are now two methods for getting at the URL parameters. The and none for setting them? That's correct. Looking at various libraries, there seems to be much more interested in paring out query parameters than for constructing them. One popular JavaScript library did have an API that took a dictionary and built a query string out of it. I imagine most folks just use the HTML Form element. MXR (hg.mozilla.org/webtools/mxr/) has an api for constructing urls (mostly parameters really). It tends to do redirects/rewrites which send most but not all of a set of parameters to another location. Another thing it sometimes tries to do is drop empty bits (input name=x value=) from the url. another thing it of course does is strip out '../' or similar variations. Note that MXR happens to mostly do its work server side, but there are bits which would do equivalent work client side, the server/client side bit is an implementation detail and I'd expect that people not caring about JS-off browsers would put much more of the code into the client and use javascript to do these manipulations. I'm sorry that I don't have time to read the current document. I'll try to do that once I finish reading my backlog.
Re: A URL API
If you really don't want to care what happened before, either do a clearParameter every time first, or define your own setParameter that just clears then appends. Append/clear is a cleaner API design in general imo, precisely because you don't have to worry about colliding with previous activity by default. A set/clear pair means that you have to explicitly check for existing data and handle it in a way that isn't completely trivial. I am not saying remove append - I am saying that just also have set, with the semantics that if you use set, its equivalent to clear;append Attempting to relegate same-name params to second-tier status isn't a good idea. It's very useful for far more than the old services that are also accessed via basic HTML forms that you stated earlier. I am not sure about that - I think a modern API design would be to just send multiple values as an array (maybe CSV or TSV). Consider how JSON values are encoded - do you have multiple values to denote arrays? neither is this the case in XML (afaik). This semantic of multiple yet different values for the same parameter is just confusing, and as you said a mess for server side. I am less optimistic than you are that it will be fixed. cheers devdtta ~TJ
Re: A URL API
On Wed, Sep 22, 2010 at 12:54 AM, Devdatta Akhawe dev.akh...@gmail.com wrote: 2) I've added two flavors of appendParameter. The first flavor takes a DOMString for a value and appends a single parameter. The second flavor takes an array of DOMStrings and appends one parameter for each array. This seemed better than using a variable number of arguments. -1 I really want the setParameter method - appendParameter now requires the developer to know what someone might have done in the past with the URL object. this can be a cause of trouble as the web application might do something that the developer doesn't expect , so I specifically want the developer to opt-in to using appendParameters. If you really don't want to care what happened before, either do a clearParameter every time first, or define your own setParameter that just clears then appends. Append/clear is a cleaner API design in general imo, precisely because you don't have to worry about colliding with previous activity by default. A set/clear pair means that you have to explicitly check for existing data and handle it in a way that isn't completely trivial. I know clearParameter is a method - but this is not the clear separation between the '2 APIs' that we talked about earlier in the thread. I remember reading about how some web application frameworks combine ?q=aq=b to q=ab at the server side, whereas some will only consider q=a and some will only consider q=b. This is such a mess - the developer should have to specifically opt-in to this. It's a mess for server-side languages/frameworks, yes. Some of them handle this incorrectly. Most of the current crop of popular ones, though, do things properly with one method that retrieves the last value and one that retrieves all values (PHP is marginal in this respect with its magic naming convention). Attempting to relegate same-name params to second-tier status isn't a good idea. It's very useful for far more than the old services that are also accessed via basic HTML forms that you stated earlier. ~TJ
Re: A URL API
On Sun, Sep 19, 2010 at 10:50 PM, Darin Fisher da...@chromium.org wrote: On Sun, Sep 19, 2010 at 10:41 PM, Boris Zbarsky bzbar...@mit.edu wrote: * A getCommonBaseSpec() method that will take two URIs and return a URI string they could both be relative to, if any. * A getRelativeSpec() method that takes two URIs and returns a string that represents one as a relative URI relative to the other (if this is possible). ^^^ these are convenient I haven't added these yet, but I certainly wouldn't rule out adding them in the future. Adam
Re: A URL API
2) I've added two flavors of appendParameter. The first flavor takes a DOMString for a value and appends a single parameter. The second flavor takes an array of DOMStrings and appends one parameter for each array. This seemed better than using a variable number of arguments. -1 I really want the setParameter method - appendParameter now requires the developer to know what someone might have done in the past with the URL object. this can be a cause of trouble as the web application might do something that the developer doesn't expect , so I specifically want the developer to opt-in to using appendParameters. I know clearParameter is a method - but this is not the clear separation between the '2 APIs' that we talked about earlier in the thread. I remember reading about how some web application frameworks combine ?q=aq=b to q=ab at the server side, whereas some will only consider q=a and some will only consider q=b. This is such a mess - the developer should have to specifically opt-in to this. cheers devdatta 3) I've added a clearParameter method. Defining these methods required some low-level URL manipulation that's not actually defined anywhere (AFAIK), so I've added a reference to my work-in-progress draft about parsing and canonicalizing URLs. Adam On Tue, Sep 21, 2010 at 3:40 PM, Ojan Vafai o...@chromium.org wrote: appendParameter/clearParameter seems fine to me. On Wed, Sep 22, 2010 at 2:53 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Sep 20, 2010 at 11:56 PM, Adam Barth w...@adambarth.com wrote: Ok. I'm sold on having an API for constructing query parameters. Thoughts on what it should look like? Here's what jQuery does: http://api.jquery.com/jQuery.get/ Essentially, you supply a JSON object containing the parameters. They also have some magical syntax for specifying multiple instances of the same parameter name. I like the easy of supplying a JSON object, but I'm not in love with the magical syntax. An alternative is to use two APIs, like we current have for reading the parameter values. jQuery's syntax isn't magical - the example they give using the query param name of 'choices[]' is doing that because PHP requires a [] at the end of the query param name to signal it that you want multiple values. It's opaque, though - you could just as easily have left off the '[]' and it would have worked the same. The switch is just whether you pass an array or a string (maybe they support numbers too?). I recommend the method be called append*, so you can use it both for first sets and later additions (this is particularly useful if you're just looping through some data). This obviously would then need a clear functionality as well. ~TJ
Re: A URL API
On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.comwrote: On 9/20/10, Julian Reschke julian.resc...@gmx.de wrote: On 20.09.2010 18:56, Garrett Smith wrote: [...] Requests that don't have lot of parameters are often simple one-liners: url = /getShipping/?zip= + zip + pid= + pid; That's exactly the kind of code that will fail once pid and zip contain things you don't expecz. What XHRs have complicated URL with a lot of query parameters? What XHRs? IOW, what are the cases where an XHR instance wants to use a lot o query params? Probably when speaking to a HTTP server designed to take input from an HTML form. -Darin
Re: A URL API
or any webservice that likes to have lots of query parameters - Google Search for example. In general, why would you not want a robust way to make complicated queries - those who are making simple queries and prefer simple one liners can continue using it. On 20 September 2010 23:42, Darin Fisher da...@chromium.org wrote: On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 9/20/10, Julian Reschke julian.resc...@gmx.de wrote: On 20.09.2010 18:56, Garrett Smith wrote: [...] Requests that don't have lot of parameters are often simple one-liners: url = /getShipping/?zip= + zip + pid= + pid; That's exactly the kind of code that will fail once pid and zip contain things you don't expecz. What XHRs have complicated URL with a lot of query parameters? What XHRs? IOW, what are the cases where an XHR instance wants to use a lot o query params? Probably when speaking to a HTTP server designed to take input from an HTML form. -Darin
Re: A URL API
Ok. I'm sold on having an API for constructing query parameters. Thoughts on what it should look like? Here's what jQuery does: http://api.jquery.com/jQuery.get/ Essentially, you supply a JSON object containing the parameters. They also have some magical syntax for specifying multiple instances of the same parameter name. I like the easy of supplying a JSON object, but I'm not in love with the magical syntax. An alternative is to use two APIs, like we current have for reading the parameter values. Adam On Mon, Sep 20, 2010 at 11:47 PM, Devdatta Akhawe dev.akh...@gmail.com wrote: or any webservice that likes to have lots of query parameters - Google Search for example. In general, why would you not want a robust way to make complicated queries - those who are making simple queries and prefer simple one liners can continue using it. On 20 September 2010 23:42, Darin Fisher da...@chromium.org wrote: On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 9/20/10, Julian Reschke julian.resc...@gmx.de wrote: On 20.09.2010 18:56, Garrett Smith wrote: [...] Requests that don't have lot of parameters are often simple one-liners: url = /getShipping/?zip= + zip + pid= + pid; That's exactly the kind of code that will fail once pid and zip contain things you don't expecz. What XHRs have complicated URL with a lot of query parameters? What XHRs? IOW, what are the cases where an XHR instance wants to use a lot o query params? Probably when speaking to a HTTP server designed to take input from an HTML form. -Darin
Re: A URL API
+1 for 2 APIs - this whole multiple parameters with the same value is too annoying imho and unnecessary for new web services . It should be there only for old services that are also accessed via basic HTML forms cheers devdatta On 20 September 2010 23:56, Adam Barth w...@adambarth.com wrote: Ok. I'm sold on having an API for constructing query parameters. Thoughts on what it should look like? Here's what jQuery does: http://api.jquery.com/jQuery.get/ Essentially, you supply a JSON object containing the parameters. They also have some magical syntax for specifying multiple instances of the same parameter name. I like the easy of supplying a JSON object, but I'm not in love with the magical syntax. An alternative is to use two APIs, like we current have for reading the parameter values. Adam On Mon, Sep 20, 2010 at 11:47 PM, Devdatta Akhawe dev.akh...@gmail.com wrote: or any webservice that likes to have lots of query parameters - Google Search for example. In general, why would you not want a robust way to make complicated queries - those who are making simple queries and prefer simple one liners can continue using it. On 20 September 2010 23:42, Darin Fisher da...@chromium.org wrote: On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 9/20/10, Julian Reschke julian.resc...@gmx.de wrote: On 20.09.2010 18:56, Garrett Smith wrote: [...] Requests that don't have lot of parameters are often simple one-liners: url = /getShipping/?zip= + zip + pid= + pid; That's exactly the kind of code that will fail once pid and zip contain things you don't expecz. What XHRs have complicated URL with a lot of query parameters? What XHRs? IOW, what are the cases where an XHR instance wants to use a lot o query params? Probably when speaking to a HTTP server designed to take input from an HTML form. -Darin
Re: A URL API
How about setParameter(name, value...) that takes var_args number of values? Alternately, it could take either a DOMString or an ArrayDOMString for the value. I prefer the var_args. Also, getParameterByName and getAllParametersByName seem unnecessarily wordy. How about getParameter/getParameterAll to match querySelector/querySelectorAll? Putting All at the end is admittedly awkward, but this is the uncommon case, so I'm OK with it for making the common case less wordy. Ojan On Tue, Sep 21, 2010 at 4:56 PM, Adam Barth w...@adambarth.com wrote: Ok. I'm sold on having an API for constructing query parameters. Thoughts on what it should look like? Here's what jQuery does: http://api.jquery.com/jQuery.get/ Essentially, you supply a JSON object containing the parameters. They also have some magical syntax for specifying multiple instances of the same parameter name. I like the easy of supplying a JSON object, but I'm not in love with the magical syntax. An alternative is to use two APIs, like we current have for reading the parameter values. Adam On Mon, Sep 20, 2010 at 11:47 PM, Devdatta Akhawe dev.akh...@gmail.com wrote: or any webservice that likes to have lots of query parameters - Google Search for example. In general, why would you not want a robust way to make complicated queries - those who are making simple queries and prefer simple one liners can continue using it. On 20 September 2010 23:42, Darin Fisher da...@chromium.org wrote: On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 9/20/10, Julian Reschke julian.resc...@gmx.de wrote: On 20.09.2010 18:56, Garrett Smith wrote: [...] Requests that don't have lot of parameters are often simple one-liners: url = /getShipping/?zip= + zip + pid= + pid; That's exactly the kind of code that will fail once pid and zip contain things you don't expecz. What XHRs have complicated URL with a lot of query parameters? What XHRs? IOW, what are the cases where an XHR instance wants to use a lot o query params? Probably when speaking to a HTTP server designed to take input from an HTML form. -Darin
Re: A URL API
On 21 September 2010 00:47, Ojan Vafai o...@chromium.org wrote:
How about setParameter(name, value...) that takes var_args number of values?
Alternately, it could take either a DOMString or an ArrayDOMString for the
value. I prefer the var_args.
What happens when I do
setParameter('x','a','b','c');
and now want to add another - I will have to do weird things like
getting the parameter via getAllParameter and then append to the array
and function.call or something like that
doesn't look very nice according to me - I like the separation into 2
APIs because I think that makes the common case of single parameter
values clean and robust
cheers
devdatta
Also, getParameterByName and getAllParametersByName seem unnecessarily
wordy. How about getParameter/getParameterAll to match
querySelector/querySelectorAll? Putting All at the end is admittedly
awkward, but this is the uncommon case, so I'm OK with it for making the
common case less wordy.
Ojan
On Tue, Sep 21, 2010 at 4:56 PM, Adam Barth w...@adambarth.com wrote:
Ok. I'm sold on having an API for constructing query parameters.
Thoughts on what it should look like? Here's what jQuery does:
http://api.jquery.com/jQuery.get/
Essentially, you supply a JSON object containing the parameters. They
also have some magical syntax for specifying multiple instances of the
same parameter name. I like the easy of supplying a JSON object, but
I'm not in love with the magical syntax. An alternative is to use two
APIs, like we current have for reading the parameter values.
Adam
On Mon, Sep 20, 2010 at 11:47 PM, Devdatta Akhawe dev.akh...@gmail.com
wrote:
or any webservice that likes to have lots of query parameters - Google
Search for example.
In general, why would you not want a robust way to make complicated
queries - those who are making simple queries and prefer simple one
liners can continue using it.
On 20 September 2010 23:42, Darin Fisher da...@chromium.org wrote:
On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith
dhtmlkitc...@gmail.com
wrote:
On 9/20/10, Julian Reschke julian.resc...@gmx.de wrote:
On 20.09.2010 18:56, Garrett Smith wrote:
[...]
Requests that don't have lot of parameters are often simple
one-liners:
url = /getShipping/?zip= + zip + pid= + pid;
That's exactly the kind of code that will fail once pid and zip
contain things you don't expecz.
What XHRs have complicated URL with a lot of query parameters?
What XHRs?
IOW, what are the cases where an XHR instance wants to use a lot o
query
params?
Probably when speaking to a HTTP server designed to take input from an
HTML
form.
-Darin
Re: A URL API
On Tue, Sep 21, 2010 at 12:51 AM, Devdatta Akhawe dev.akh...@gmail.com wrote:
On 21 September 2010 00:47, Ojan Vafai o...@chromium.org wrote:
How about setParameter(name, value...) that takes var_args number of values?
Alternately, it could take either a DOMString or an ArrayDOMString for the
value. I prefer the var_args.
What happens when I do
setParameter('x','a','b','c');
and now want to add another - I will have to do weird things like
getting the parameter via getAllParameter and then append to the array
and function.call or something like that
doesn't look very nice according to me - I like the separation into 2
APIs because I think that makes the common case of single parameter
values clean and robust
Perhaps appendParameter(x, a, b, c) ?
Adam
Re: A URL API
On 9/21/10, Ojan Vafai o...@chromium.org wrote: How about setParameter(name, value...) that takes var_args number of values? Alternately, it could take either a DOMString or an ArrayDOMString for the value. I prefer the var_args. Why? A user-defined fallback will be necessary for a while. The downside of using varargs is that any user-defined fallback has to resort to using the arguments object. Your alternate doesn't have that problem. -- Garrett
Re: A URL API
On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: IOW, what are the cases where an XHR instance wants to use a lot o query params? I'm sure there are other examples, and it depends by what you mean by a lot, but here are all the parameters that Google Reader sends when requesting feed data (Reader uses the goog.Uri classes from the Closure library that Ojan mentioned earlier): trans:true ot:1282413600 r:n xt:user/14548369432350969777/state/com.google/read sharers:CKfbjpeeFxgB n:20 refresh:true ck:1285006428691 client:scroll Mihai
Re: A URL API
Hi, Adam- I really like this idea. Of course there are scripts out there that do most (all?) of this, but exposing it as an interface seems useful to me. I proposed something similar in my SVG Params spec [1][2][3], though yours is better thought out. One difference is that I was specifically looking at parameters, not merely as a function of the URL, but through any mechanism that the language provides; for example, HTML can pass parameters into a file referenced through the object element with child param elements. Do you think there's some way to reconcile that with your proposal? [1] http://www.w3.org/TR/SVGParam/ [2] http://dev.w3.org/SVG/modules/param/master/SVGParam.html [3] http://dev.w3.org/SVG/modules/param/master/SVGParamPrimer.html Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Adam Barth wrote (on 9/17/10 2:05 PM): On Fri, Sep 17, 2010 at 10:27 AM, Adam Barthw...@adambarth.com wrote: On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisherda...@chromium.org wrote: On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschkejulian.resc...@gmx.de wrote: That sounds good to me. In general I think it would be great if there were standard APIs for URI/IRI construction, parsing and resolution... Yes, that sounds pretty good to me too. This has annoyed me for a while too. I'll write up a spec. Here's a sketch: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en Adam
Re: A URL API
Perhaps appendParameter(x, a, b, c) ? where appendParameter is the second API - separate from setParameter? so appendParmeter(x',a,b,c); setParameter(x,a) would result in ?x=a and without the second function call it would be ?x=ax=bx=c I am fine with this. cheers devdatta Adam
Re: A URL API
On Mon, Sep 20, 2010 at 11:56 PM, Adam Barth w...@adambarth.com wrote: Ok. I'm sold on having an API for constructing query parameters. Thoughts on what it should look like? Here's what jQuery does: http://api.jquery.com/jQuery.get/ Essentially, you supply a JSON object containing the parameters. They also have some magical syntax for specifying multiple instances of the same parameter name. I like the easy of supplying a JSON object, but I'm not in love with the magical syntax. An alternative is to use two APIs, like we current have for reading the parameter values. jQuery's syntax isn't magical - the example they give using the query param name of 'choices[]' is doing that because PHP requires a [] at the end of the query param name to signal it that you want multiple values. It's opaque, though - you could just as easily have left off the '[]' and it would have worked the same. The switch is just whether you pass an array or a string (maybe they support numbers too?). I recommend the method be called append*, so you can use it both for first sets and later additions (this is particularly useful if you're just looping through some data). This obviously would then need a clear functionality as well. ~TJ
Re: A URL API
appendParameter/clearParameter seems fine to me. On Wed, Sep 22, 2010 at 2:53 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Mon, Sep 20, 2010 at 11:56 PM, Adam Barth w...@adambarth.com wrote: Ok. I'm sold on having an API for constructing query parameters. Thoughts on what it should look like? Here's what jQuery does: http://api.jquery.com/jQuery.get/ Essentially, you supply a JSON object containing the parameters. They also have some magical syntax for specifying multiple instances of the same parameter name. I like the easy of supplying a JSON object, but I'm not in love with the magical syntax. An alternative is to use two APIs, like we current have for reading the parameter values. jQuery's syntax isn't magical - the example they give using the query param name of 'choices[]' is doing that because PHP requires a [] at the end of the query param name to signal it that you want multiple values. It's opaque, though - you could just as easily have left off the '[]' and it would have worked the same. The switch is just whether you pass an array or a string (maybe they support numbers too?). I recommend the method be called append*, so you can use it both for first sets and later additions (this is particularly useful if you're just looping through some data). This obviously would then need a clear functionality as well. ~TJ
Re: A URL API
On Sun, Sep 19, 2010 at 10:56 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/20/10 1:51 AM, Adam Barth wrote: 1) The reference chain for actually parsing a URI terminates in HTML5 referencing the IRI RFC, which doesn't seem to define a parsing algorithm. Did I just miss it? I'm working on fixing that problem too: http://github.com/abarth/url-spec/blob/master/drafts/url.txt Ah, excellent. And even better, it already has open issues on the things I wanted to double-check. ;) That document is pretty rough, but I welcome any feedback you have. Adam
Re: A URL API
On 20.09.2010 07:51, Adam Barth wrote: ... 2) Why lastPathComponent as opposed to, say, fileName? Renamed to fileName. ... -1 Please stay consistent with the terminology in the URI spec. Best regards, Julian
Re: A URL API
On Mon, Sep 20, 2010 at 4:27 PM, Adam Barth w...@adambarth.com wrote: On Sun, Sep 19, 2010 at 10:48 PM, Devdatta Akhawe dev.akh...@gmail.com wrote: 1) There are now two methods for getting at the URL parameters. The and none for setting them? That's correct. Looking at various libraries, there seems to be much more interested in paring out query parameters than for constructing them. One popular JavaScript library did have an API that took a dictionary and built a query string out of it. I imagine most folks just use the HTML Form element. That's not true of Google's Closure library: http://closure-library.googlecode.com/svn/docs/class_goog_Uri.html (see the set* methods).
Re: A URL API
On 20.09.2010 08:27, Adam Barth wrote: On Sun, Sep 19, 2010 at 10:48 PM, Devdatta Akhawedev.akh...@gmail.com wrote: 1) There are now two methods for getting at the URL parameters. The and none for setting them? That's correct. Looking at various libraries, there seems to be much more interested in paring out query parameters than for constructing them. One popular JavaScript library did have an API that took a dictionary and built a query string out of it. I imagine most folks just use the HTML Form element. ... If a new standard API is added, it also should cover construction. Construction is hard, due to the different escaping rules for paths, query parameters etc. Keep in mind that the original use case was making life easier for people using XmlHttpRequest, and that covers many more use cases than forms. Best regards, Julian
Re: A URL API
On 20.09.2010 09:22, Garrett Smith wrote: ... I see setParameterValues there. Useful to build URLs for XHR. But OTOH -- Ajax that is using a lot of parameters, might be better using a form. Usually Ajax requests are simple requests -- not a large form submission. Sorry just have to be devils advocate on the necessity of the thing. ... How do you use a form to build a request other than GET/POST?
Re: A URL API
On 20.09.2010 10:01, Adam Barth wrote: On Mon, Sep 20, 2010 at 12:34 AM, Julian Reschkejulian.resc...@gmx.de wrote: On 20.09.2010 09:22, Garrett Smith wrote: ... I see setParameterValues there. Useful to build URLs for XHR. But OTOH -- Ajax that is using a lot of parameters, might be better using a form. Usually Ajax requests are simple requests -- not a large form submission. Sorry just have to be devils advocate on the necessity of the thing. ... How do you use a form to build a request other than GET/POST? Using the method attribute of the form element. OK. So I set the method attribute to FOOBAR, and then how do I proceed generating an HTTP request from there? Best regards, Julian
Re: A URL API
On Mon, 20 Sep 2010 10:01:01 +0200, Adam Barth w...@adambarth.com wrote: Using the method attribute of the form element. It will not get you further than GET/POST; and PUT/DELETE with same-origin limitation. It also does not allow for custom headers, custom entity body, etc. -- Anne van Kesteren http://annevankesteren.nl/
Re: A URL API
On 9/20/10, Julian Reschke julian.resc...@gmx.de wrote: On 20.09.2010 09:22, Garrett Smith wrote: ... I see setParameterValues there. Useful to build URLs for XHR. But OTOH -- Ajax that is using a lot of parameters, might be better using a form. Usually Ajax requests are simple requests -- not a large form submission. Sorry just have to be devils advocate on the necessity of the thing. ... How do you use a form to build a request other than GET/POST? No idea; I wouldn't expect it to work, even if some browser actually supported something other than GET|POST. I've always used get or post and that's what's stated in HTML4. http://www.w3.org/TR/html401/interact/forms.html#adef-method Might a large-ish form request, a standard form submission be a better alternative to XHR? Requests that don't have lot of parameters are often simple one-liners: url = /getShipping/?zip= + zip + pid= + pid; What XHRs have complicated URL with a lot of query parameters? Garrett
Re: A URL API
On 20.09.2010 18:56, Garrett Smith wrote: No idea; I wouldn't expect it to work, even if some browser actually supported something other than GET|POST. I've always used get or post and that's what's stated in HTML4. http://www.w3.org/TR/html401/interact/forms.html#adef-method Might a large-ish form request, a standard form submission be a better alternative to XHR? Depends on the application. One reason to use XHR is that you want to interact with an HTTP service that hasn't been written for a web browser. Whether services like this require complicated URI construction is a separate issue. Some do. And I'm pretty sure that people *will* get URI construction wrong due to delimiters, non-ASCII characters and so on. Requests that don't have lot of parameters are often simple one-liners: url = /getShipping/?zip= + zip + pid= + pid; That's exactly the kind of code that will fail once pid and zip contain things you don't expecz. What XHRs have complicated URL with a lot of query parameters? What XHRs? Best regards, Julian
Re: A URL API
That would be different behavior than what Location and HTMLAnchorElement do; they unescape various componenents. Is the benefit worth the divergence? As a side note, an out-of-document HTMLAnchorElement already provides most of the functionality of this interface. Things it can't do: - Resolve a relative URL against no base at all (probably not very useful since the interface can only represent an absolute URL). - Resolve against an arbitrary base (maybe you could do it awkwardly using base tag tricks). - Read or write the lastPathComponent or origin without further parsing (should origin really be writable? That's kind of weird...) - Read search parameters conveniently without parsing. It might be nice to provide the parts of this that make sense on HTMLAnchorElement and Location, then see if a new interface really pulls its weight. I idea too. I would rather extend Location to include these features, so they would be immediately available in links and the location object. And make Location into a constructor new Location(url, base)
Re: A URL API
hi Is the word 'hash' for fragment identifiers common? I personally prefer the attribute being called 'fragment' or 'fragmentID' over 'hash' - its the standard afaik in all the RFCs. regards devdatta On 19 September 2010 15:47, João Eiras joao.ei...@gmail.com wrote: That would be different behavior than what Location and HTMLAnchorElement do; they unescape various componenents. Is the benefit worth the divergence? As a side note, an out-of-document HTMLAnchorElement already provides most of the functionality of this interface. Things it can't do: - Resolve a relative URL against no base at all (probably not very useful since the interface can only represent an absolute URL). - Resolve against an arbitrary base (maybe you could do it awkwardly using base tag tricks). - Read or write the lastPathComponent or origin without further parsing (should origin really be writable? That's kind of weird...) - Read search parameters conveniently without parsing. It might be nice to provide the parts of this that make sense on HTMLAnchorElement and Location, then see if a new interface really pulls its weight. I idea too. I would rather extend Location to include these features, so they would be immediately available in links and the location object. And make Location into a constructor new Location(url, base)
Re: A URL API
On Sun, Sep 19, 2010 at 5:03 PM, Devdatta Akhawe dev.akh...@gmail.com wrote: hi Is the word 'hash' for fragment identifiers common? I personally prefer the attribute being called 'fragment' or 'fragmentID' over 'hash' - its the standard afaik in all the RFCs. 'hash' is the name given to the fragment identifier in the Location object. It's pretty common. ~TJ
Re: A URL API
On Fri, Sep 17, 2010 at 5:48 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Sep 17, 2010 at 5:43 PM, Adam Barth w...@adambarth.com wrote: I've removed the searchParameters attribute from the URL interface for the time being. We can consider adding it back at a later time. ;_; Just today my cubemate asked me if there was any way to get at the search parameters of a URL without parsing it himself. I replied No, but abarth started working on an API for it today.. That said, Garrett's right. The values of the dict should be arrays. Most of the time they'll be single-element arrays, but the benefit of having a consistent type of value at all times is better than the benefit of being able to omit [0] from parts of your code. I've updated the document: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en# Changes: 1) There are now two methods for getting at the URL parameters. The easy one, which just returns the last value if there are more than one parameter with the same name (I checked a bunch of libraries and using the last of duplicates seemed to be more popular), and the advanced one, which returns an array containing all of the values. 2) The origin attribute is now readonly. Once I wired up the origin attribute to the actual definition of how to compute the origin of a URL, it became obvious that we don't want to support assigning to the attribute. In particular, it doesn't seems particularly meaningful to assign the string null to the attribute even though that's a perfectly reasonable value for the attribute to return. 3) I've added definitions for what the interface actually does. In response to folks who think we should add these APIs to HTMLAnchorElement and Location, I agree. Currently, the draft is written to refer to HTML5 for the definitions of the common elements, but we could easily reverse that dependency or incorporate this API into HTML5. Adam
Re: A URL API
On 9/20/10 1:02 AM, Adam Barth wrote: I've updated the document: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en# General comments based on a quick read (and ignoring various typos that I figure we'll fix in due course): 1) The reference chain for actually parsing a URI terminates in HTML5 referencing the IRI RFC, which doesn't seem to define a parsing algorithm. Did I just miss it? 2) Why lastPathComponent as opposed to, say, fileName? 3) Why is lastPathComponent readonly? 4) Things Gecko has on its URI objects that this seems to be missing and that might be useful and aren't obviously available via existing facilities of this interface: * An equals() method that takes another URI object * An 'asciiSpec' property (Host IDN-escaped as needed, other parts URL-escaped). * An 'asciiHost' property * A 'param' property (for things following ';') * A 'directory' property (which may be similar to getting the pathname and then dropping everything after the last '/'... not sure). * fileBaseName and fileExtension (URI might not be the right place for these, though). * A getCommonBaseSpec() method that will take two URIs and return a URI string they could both be relative to, if any. * A getRelativeSpec() method that takes two URIs and returns a string that represents one as a relative URI relative to the other (if this is possible). -Boris
Re: A URL API
1) There are now two methods for getting at the URL parameters. The and none for setting them? cheers devdatta 2) The origin attribute is now readonly. Once I wired up the origin attribute to the actual definition of how to compute the origin of a URL, it became obvious that we don't want to support assigning to the attribute. In particular, it doesn't seems particularly meaningful to assign the string null to the attribute even though that's a perfectly reasonable value for the attribute to return. 3) I've added definitions for what the interface actually does. In response to folks who think we should add these APIs to HTMLAnchorElement and Location, I agree. Currently, the draft is written to refer to HTML5 for the definitions of the common elements, but we could easily reverse that dependency or incorporate this API into HTML5. Adam
Re: A URL API
On Sun, Sep 19, 2010 at 10:41 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/20/10 1:02 AM, Adam Barth wrote: I've updated the document: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en# General comments based on a quick read (and ignoring various typos that I figure we'll fix in due course): 1) The reference chain for actually parsing a URI terminates in HTML5 referencing the IRI RFC, which doesn't seem to define a parsing algorithm. Did I just miss it? 2) Why lastPathComponent as opposed to, say, fileName? 3) Why is lastPathComponent readonly? 4) Things Gecko has on its URI objects that this seems to be missing and that might be useful and aren't obviously available via existing facilities of this interface: * An equals() method that takes another URI object * An 'asciiSpec' property (Host IDN-escaped as needed, other parts URL-escaped). * An 'asciiHost' property asciiSpec/Host is the canonical form, which is what Location currently outputs. gecko's URI class has the UTF-8 spec/host attributes to be more friendly to UI code that might prefer the non-IDN version of the strings. * A 'param' property (for things following ';') This one seems unused as best as I can tell. * A 'directory' property (which may be similar to getting the pathname and then dropping everything after the last '/'... not sure). * fileBaseName and fileExtension (URI might not be the right place for these, though). ^^^ extracting those is pretty simple given the currently proposed interface. * A getCommonBaseSpec() method that will take two URIs and return a URI string they could both be relative to, if any. * A getRelativeSpec() method that takes two URIs and returns a string that represents one as a relative URI relative to the other (if this is possible). ^^^ these are convenient -Darin -Boris
Re: A URL API
On Fri, Sep 17, 2010 at 9:52 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 17, 2010, at 1:01 PM, Adam Barth wrote: Another piece of functionality that's missing from HTMLAnchorElement is the automatic stringification of URL objects. That lets you pass URL objects into APIs that expect URLs represented as strings. It's unlikely that we'd want to add that part of the interface to HTMLAnchorElement. That does not match my recollection or testing: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%3E%0A%3Ca%20href%3D%22http%3A%2F%2Fsome-domain.com%2Fsome%2Fpath%23frag%22%20id%3Dtest%3E%3C%2Fa%3E%0A%3Cscript%3E%0Adocument.write(document.getElementById(%22test%22))%3B%0A%3C%2Fscript%3E Woah, that's pretty cool. Adam
A URL API
On Fri, Sep 17, 2010 at 10:27 AM, Adam Barth w...@adambarth.com wrote: On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisher da...@chromium.org wrote: On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke julian.resc...@gmx.de wrote: That sounds good to me. In general I think it would be great if there were standard APIs for URI/IRI construction, parsing and resolution... Yes, that sounds pretty good to me too. This has annoyed me for a while too. I'll write up a spec. Here's a sketch: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en Adam
Re: A URL API
Adam Barth wrote:
On Fri, Sep 17, 2010 at 10:27 AM, Adam Barth w...@adambarth.com wrote:
On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke julian.resc...@gmx.de
wrote:
That sounds good to me. In general I think it would be great if there were
standard APIs for URI/IRI construction, parsing and resolution...
Yes, that sounds pretty good to me too.
This has annoyed me for a while too. I'll write up a spec.
Here's a sketch:
https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en
might I suggest naming it URI or IRI, and the addition of some or all of
the following methods:
bool isAbsolute();
URI defrag();
URI toAbsolute();
URI resolveReference(in URI reference);
the following methods exposed to handle complicated URIs:
u = new URI('http://ex.org/a/b/c/d/../.././egg#s/../x');
u.isAbsolute();- boolean
u.defrag();-
'http://ex.org/a/b/c/d/../.././egg'
u.toAbsolute();- 'http://ex.org/a/b/egg'
and to resolve relative URIs + URI References:
u = new URI('http://ex.org/a/b/c/d');
u.resolveReference('../.././n?x=y'); - 'http://ex.org/a/n?x=y'
ps: I'll happily implement this interface Javascript whenever as I've
already got something similar: http://github.com/webr3/URI
Best,
Nathan
Re: A URL API
On Fri, Sep 17, 2010 at 11:05 AM, Adam Barth w...@adambarth.com wrote: On Fri, Sep 17, 2010 at 10:27 AM, Adam Barth w...@adambarth.com wrote: On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisher da...@chromium.org wrote: On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke julian.resc...@gmx.de wrote: That sounds good to me. In general I think it would be great if there were standard APIs for URI/IRI construction, parsing and resolution... Yes, that sounds pretty good to me too. This has annoyed me for a while too. I'll write up a spec. Here's a sketch: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en Adam Nice! Is there any implicit unescaping done when reading those members? I'd hope for the answer to be no :-) When does canonicalization happen? Only when you call href? Or, does it happen when you readback any attribute? -Darin
Re: A URL API
On Fri, Sep 17, 2010 at 11:16 AM, Darin Fisher da...@chromium.org wrote:
On Fri, Sep 17, 2010 at 11:05 AM, Adam Barth w...@adambarth.com wrote:
On Fri, Sep 17, 2010 at 10:27 AM, Adam Barth w...@adambarth.com wrote:
On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisher da...@chromium.org
wrote:
On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke julian.resc...@gmx.de
wrote:
That sounds good to me. In general I think it would be great if there
were
standard APIs for URI/IRI construction, parsing and resolution...
Yes, that sounds pretty good to me too.
This has annoyed me for a while too. I'll write up a spec.
Here's a sketch:
https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en
Nice! Is there any implicit unescaping done when reading those members?
I'd hope for the answer to be no :-)
That's a good question. I'd expect them to just be textual segments
of the URL so you could reconstruct the URL by concatenating them.
When does canonicalization happen? Only when you call href? Or, does it
happen when you readback any attribute?
I think it should happen when you read back any attribute. That seems
safest from a security perspective since you're aways reading back
something canonical.
On Fri, Sep 17, 2010 at 11:16 AM, Nathan nat...@webr3.org wrote:
might I suggest naming it URI or IRI, and the addition of some or all of the
following methods:
I'd like to avoid bikeshedding about the name at this time. We can
certainly discuss that in the future.
bool isAbsolute();
URI toAbsolute();
The interface will always represent an absolute URL.
URI defrag();
What does this mean? If you mean remove the fragment, you can do
that by assigning null to the hash property.
URI resolveReference(in URI reference);
You can do this with the constructor:
var resolved_url = new URL(relative_url, base_url);
the following methods exposed to handle complicated URIs:
u = new URI('http://ex.org/a/b/c/d/../.././egg#s/../x');
u.isAbsolute(); - boolean
u.defrag(); -
'http://ex.org/a/b/c/d/../.././egg'
u.toAbsolute(); - 'http://ex.org/a/b/egg'
and to resolve relative URIs + URI References:
u = new URI('http://ex.org/a/b/c/d');
u.resolveReference('../.././n?x=y'); - 'http://ex.org/a/n?x=y'
ps: I'll happily implement this interface Javascript whenever as I've
already got something similar: http://github.com/webr3/URI
Thanks. It would certainly be helpful to have a sample implementation
in JavaScript.
Adam
Re: A URL API
On Fri, 17 Sep 2010 20:51:27 +0200, Maciej Stachowiak m...@apple.com wrote: That would be different behavior than what Location and HTMLAnchorElement do; they unescape various componenents. Is the benefit worth the divergence? As a side note, an out-of-document HTMLAnchorElement already provides most of the functionality of this interface. Things it can't do: - Resolve a relative URL against no base at all (probably not very useful since the interface can only represent an absolute URL). - Resolve against an arbitrary base (maybe you could do it awkwardly using base tag tricks). You could actually just use xml:base. - Read or write the lastPathComponent or origin without further parsing (should origin really be writable? That's kind of weird...) - Read search parameters conveniently without parsing. It might be nice to provide the parts of this that make sense on HTMLAnchorElement and Location, then see if a new interface really pulls its weight. We have navigator.resolveURL(url) in HTML5. I believe that was mostly for Web Workers. Probably because in Workers you cannot have stray a elements, or maybe because we just forgot about using a... (Not really been involved in that discussion.) -- Anne van Kesteren http://annevankesteren.nl/
Re: A URL API
On Fri, Sep 17, 2010 at 11:51 AM, Maciej Stachowiak m...@apple.com wrote:
On Sep 17, 2010, at 11:36 AM, Adam Barth wrote:
On Fri, Sep 17, 2010 at 11:16 AM, Darin Fisher da...@chromium.org wrote:
On Fri, Sep 17, 2010 at 11:05 AM, Adam Barth w...@adambarth.com wrote:
Here's a sketch:
https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en
Nice! Is there any implicit unescaping done when reading those members?
I'd hope for the answer to be no :-)
That's a good question. I'd expect them to just be textual segments
of the URL so you could reconstruct the URL by concatenating them.
That would be different behavior than what Location and HTMLAnchorElement do;
they unescape various componenents. Is the benefit worth the divergence?
It's probably worth being consistent even if it's slightly less
desirable for authors.
As a side note, an out-of-document HTMLAnchorElement already provides most of
the functionality of this interface. Things it can't do:
- Resolve a relative URL against no base at all (probably not very useful
since the interface can only represent an absolute URL).
- Resolve against an arbitrary base (maybe you could do it awkwardly using
base tag tricks).
- Read or write the lastPathComponent or origin without further parsing
(should origin really be writable? That's kind of weird...)
Making origin writeable seems to make about as much sense as making
the protocol writable. I'm not sure it's that useful, but I also
don't see a reason to forbid it.
- Read search parameters conveniently without parsing.
This is something I've often wanted when authoring HTML documents.
It might be nice to provide the parts of this that make sense on
HTMLAnchorElement and Location, then see if a new interface really pulls its
weight.
Another piece of functionality that's missing from HTMLAnchorElement
is the automatic stringification of URL objects. That lets you pass
URL objects into APIs that expect URLs represented as strings. It's
unlikely that we'd want to add that part of the interface to
HTMLAnchorElement.
On Fri, Sep 17, 2010 at 11:56 AM, Anne van Kesteren ann...@opera.com wrote:
We have navigator.resolveURL(url) in HTML5. I believe that was mostly for
Web Workers. Probably because in Workers you cannot have stray a elements,
or maybe because we just forgot about using a... (Not really been involved
in that discussion.)
Indeed. Workers cannot have DOM elements, which means using a non-DOM
object to parse URLs makes URL parsing functionality available to
workers. This combines especially well with the XMLHttpRequest use
cases because XMLHttpRequest is a popular API for use in workers.
On Fri, Sep 17, 2010 at 11:57 AM, Garrett Smith dhtmlkitc...@gmail.com wrote:
Where is Dictionary defined?
It might not be defined yet.
What are the values for searchParameters
-- can they be strings or are they only array;
In JavaScript, I'd imagine implementing them as a normal JavaScript
object with property names that correspond to the URL parameters.
var x = new URL(http://example.net/?title=footitle=bar);
x.searchParameters.title;
?
The specification will define which result we get. We'll want to look
at other parameter parsing libraries to see if the first or last
occurrence of a parameter is the more popular semantics.
What happens if the constructor is passed a url that is not
well-formed or unparseable per http://tools.ietf.org/html/rfc3986?
You'll likely end up with a URL object with a lot of null values for
URL components.
What about javascript: pseudo-protocol?
That should work fine.
Why not make searchParams live? And why not make it so that
x.searchParams.add(title, bar); modifies the entry for that?
I think it's more elegant if searchParameters is just a plain old dictionary.
My 2007 ES4 proposal had more, e.g. setParameterMap, which takes an
object and sets values on the URI.
x.setParameterMap({ name : fee, val: 12, relatedPIDs : [3aw34, 2345f] })
I'm not sure that's worth doing in the first version. If there's
sufficient demand, then we can add that in a future version.
When are components percent-encoded?
Whenever you read from the object, you observe the canonicalized
version of the URL.
Should protocol be named scheme? I'm aware that browsers have
location.protocol pointing to the scheme though some schemes e.g.
mailto, geo are not also protocols.
I chose the names to be consistent with the other parts of the
platform that name the parts of URLs. These names are certainly not
ideal, but consistency seems more valuable than these distinctiosn.
Adam
Re: A URL API
On 9/17/10, Adam Barth w...@adambarth.com wrote: On Fri, Sep 17, 2010 at 11:51 AM, Maciej Stachowiak m...@apple.com wrote: On Sep 17, 2010, at 11:36 AM, Adam Barth wrote: On Fri, Sep 17, 2010 at 11:16 AM, Darin Fisher da...@chromium.org wrote: On Fri, Sep 17, 2010 at 11:05 AM, Adam Barth w...@adambarth.com wrote: Here's a sketch: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en Nice! Is there any implicit unescaping done when reading those members? I'd hope for the answer to be no :-) That's a good question. I'd expect them to just be textual segments of the URL so you could reconstruct the URL by concatenating them. That would be different behavior than what Location and HTMLAnchorElement do; they unescape various componenents. Is the benefit worth the divergence? It's probably worth being consistent even if it's slightly less desirable for authors. As a side note, an out-of-document HTMLAnchorElement already provides most of the functionality of this interface. Things it can't do: - Resolve a relative URL against no base at all (probably not very useful since the interface can only represent an absolute URL). - Resolve against an arbitrary base (maybe you could do it awkwardly using base tag tricks). - Read or write the lastPathComponent or origin without further parsing (should origin really be writable? That's kind of weird...) Making origin writeable seems to make about as much sense as making the protocol writable. I'm not sure it's that useful, but I also don't see a reason to forbid it. - Read search parameters conveniently without parsing. This is something I've often wanted when authoring HTML documents. It might be nice to provide the parts of this that make sense on HTMLAnchorElement and Location, then see if a new interface really pulls its weight. Another piece of functionality that's missing from HTMLAnchorElement is the automatic stringification of URL objects. That lets you pass URL objects into APIs that expect URLs represented as strings. It's unlikely that we'd want to add that part of the interface to HTMLAnchorElement. On Fri, Sep 17, 2010 at 11:56 AM, Anne van Kesteren ann...@opera.com wrote: We have navigator.resolveURL(url) in HTML5. I believe that was mostly for Web Workers. Probably because in Workers you cannot have stray a elements, or maybe because we just forgot about using a... (Not really been involved in that discussion.) Indeed. Workers cannot have DOM elements, which means using a non-DOM object to parse URLs makes URL parsing functionality available to workers. This combines especially well with the XMLHttpRequest use cases because XMLHttpRequest is a popular API for use in workers. On Fri, Sep 17, 2010 at 11:57 AM, Garrett Smith dhtmlkitc...@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. What are the values for searchParameters -- can they be strings or are they only array; In JavaScript, I'd imagine implementing them as a normal JavaScript object with property names that correspond to the URL parameters. var x = new URL(http://example.net/?title=footitle=bar); x.searchParameters.title; ? SO you're saying that x.searchParameters.title is an object with property names that correspond to URL parameters -- again -- makes no sense. It looks like you didn't understand question so I'll rephrase and elaborate: 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? And what of the prototype of that Dictionary? Another object with nonstandard catchall behavior? No thanks on that. What is the value of x.searchParameters.valueOf? undefined? A function? Null? Storage also has live-Dictionary features but does not use Dictionary. Seems like a common interface. http://dev.w3.org/html5/webstorage/#storage-0 get/set/remove/clear all make sense there, but so do batch adds, e.g. setItems(obj). 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. -- Garrett
Re: A URL API
On Fri, Sep 17, 2010 at 2:39 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 9/17/10, Adam Barth w...@adambarth.com wrote: On Fri, Sep 17, 2010 at 11:57 AM, Garrett Smith dhtmlkitc...@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. I wrote the word Dictionary there, and I had a clear idea what I had in mind, but I'm not sure whether that idea has been written down anywhere. What are the values for searchParameters -- can they be strings or are they only array; In JavaScript, I'd imagine implementing them as a normal JavaScript object with property names that correspond to the URL parameters. var x = new URL(http://example.net/?title=footitle=bar); x.searchParameters.title; ? SO you're saying that x.searchParameters.title is an object with property names that correspond to URL parameters -- again -- makes no sense. It looks like you didn't understand question so I'll rephrase and elaborate: 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. And what of the prototype of that Dictionary? Object.prototype. Another object with nonstandard catchall behavior? No. No thanks on that. What is the value of x.searchParameters.valueOf? undefined? A function? Null? Object.prototype.valueOf Storage also has live-Dictionary features but does not use Dictionary. Seems like a common interface. http://dev.w3.org/html5/webstorage/#storage-0 get/set/remove/clear all make sense there, but so do batch adds, e.g. setItems(obj). 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. 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. Adam
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 dhtmlkitc...@gmail.com wrote:
On 9/17/10, Adam Barth w...@adambarth.com wrote:
On Fri, Sep 17, 2010 at 2:39 PM, Garrett Smith dhtmlkitc...@gmail.com
wrote:
On 9/17/10, Adam Barth w...@adambarth.com wrote:
On Fri, Sep 17, 2010 at 11:57 AM, Garrett Smith dhtmlkitc...@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
Re: A URL API
On Fri, Sep 17, 2010 at 5:43 PM, Adam Barth w...@adambarth.com wrote: I've removed the searchParameters attribute from the URL interface for the time being. We can consider adding it back at a later time. ;_; Just today my cubemate asked me if there was any way to get at the search parameters of a URL without parsing it himself. I replied No, but abarth started working on an API for it today.. That said, Garrett's right. The values of the dict should be arrays. Most of the time they'll be single-element arrays, but the benefit of having a consistent type of value at all times is better than the benefit of being able to omit [0] from parts of your code. ~TJ
Re: A URL API
Tab Atkins Jr. wrote: On Fri, Sep 17, 2010 at 5:43 PM, Adam Barth w...@adambarth.com wrote: I've removed the searchParameters attribute from the URL interface for the time being. We can consider adding it back at a later time. ;_; Just today my cubemate asked me if there was any way to get at the search parameters of a URL without parsing it himself. I replied No, but abarth started working on an API for it today.. That said, Garrett's right. The values of the dict should be arrays. Most of the time they'll be single-element arrays, but the benefit of having a consistent type of value at all times is better than the benefit of being able to omit [0] from parts of your code. +1 in every way, and if somebody wanted to miss the [0] they could make a simple get function which returned array or single element based on array.length, in userland. regards, nathan
Re: A URL API
On 9/17/10, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Sep 17, 2010 at 5:43 PM, Adam Barth w...@adambarth.com wrote: I've removed the searchParameters attribute from the URL interface for the time being. We can consider adding it back at a later time. ;_; Just today my cubemate asked me if there was any way to get at the search parameters of a URL without parsing it himself. I replied No, but abarth started working on an API for it today.. You mean you didn't mention that I drafted a much better one over two years ago? And you felt this API was worth mentioning? My criticism is spot-on and appropriate. Cursory, dismissive and thoughtless replies are as inappropriate and counterproductive as flippant messages I'm seeing in my inbox. And I'm not about to be pigeonholed or scapegoated into being the bad guy here. Make sense? That said, Garrett's right. My arguments are supported by the reasons that I provided; nothing more, nothing less. Garrett
Re: A URL API
hi You mean you didn't mention that I drafted a much better one over two years ago? Garrett : could you send a link to your ES4 draft/proposal ? My simple google skills couldn't find it. thanks devdatta And you felt this API was worth mentioning? My criticism is spot-on and appropriate. Cursory, dismissive and thoughtless replies are as inappropriate and counterproductive as flippant messages I'm seeing in my inbox. And I'm not about to be pigeonholed or scapegoated into being the bad guy here. Make sense? That said, Garrett's right. My arguments are supported by the reasons that I provided; nothing more, nothing less. Garrett
Re: A URL API
On Sep 17, 2010, at 1:01 PM, Adam Barth wrote: On Fri, Sep 17, 2010 at 11:51 AM, Maciej Stachowiak m...@apple.com wrote: It might be nice to provide the parts of this that make sense on HTMLAnchorElement and Location, then see if a new interface really pulls its weight. Another piece of functionality that's missing from HTMLAnchorElement is the automatic stringification of URL objects. That lets you pass URL objects into APIs that expect URLs represented as strings. It's unlikely that we'd want to add that part of the interface to HTMLAnchorElement. That does not match my recollection or testing: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%3E%0A%3Ca%20href%3D%22http%3A%2F%2Fsome-domain.com%2Fsome%2Fpath%23frag%22%20id%3Dtest%3E%3C%2Fa%3E%0A%3Cscript%3E%0Adocument.write(document.getElementById(%22test%22))%3B%0A%3C%2Fscript%3E Good point about the Worker use case where there is no DOM. Regards, Maciej
Re: A URL API
On 9/17/10, Devdatta Akhawe dev.akh...@gmail.com wrote: hi You mean you didn't mention that I drafted a much better one over two years ago? Garrett : could you send a link to your ES4 draft/proposal ? My simple google skills couldn't find it. I thought I linked to that earlier but don't see it now. Sorry and thanks for pointing it out. http://dhtmlkitchen.com/rec/URI.html Untouched for 3 years now, has some broken links, including a nostalgic link to Sun Microsystems. That API put the parameter map right into the URI object itself. I now see that as a design mistake. The LiveDictionary would make the object's interface simpler by moving the removeParameter, deleteParameter, etc to the generic Dictionary interface. [...] Regards, Garrett
