From Michael.McMahon at Sun.COM Mon Jul 16 09:35:01 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Mon, 16 Jul 2007 17:35:01 +0100 Subject: [Fwd: Re: URLEncodedQueryString] Message-ID: <469B9E35.6030404@sun.com> -------------- next part -------------- An embedded message was scrubbed... From: "Max (Weijun) Wang" Subject: Re: URLEncodedQueryString Date: Mon, 16 Jul 2007 22:19:13 +0800 Size: 2677 Url: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070716/1598b11c/attachment.mht From Michael.McMahon at Sun.COM Mon Jul 16 09:35:24 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Mon, 16 Jul 2007 17:35:24 +0100 Subject: [Fwd: Re: URLEncodedQueryString] Message-ID: <469B9E4C.7090704@sun.com> -------------- next part -------------- An embedded message was scrubbed... From: Christopher Hegarty - Sun Microsystems Ireland Subject: Re: URLEncodedQueryString Date: Mon, 16 Jul 2007 15:27:40 +0100 Size: 3949 Url: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070716/278db798/attachment.mht From Michael.McMahon at Sun.COM Mon Jul 16 09:35:41 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Mon, 16 Jul 2007 17:35:41 +0100 Subject: [Fwd: Re: URLEncodedQueryString] Message-ID: <469B9E5D.8030005@sun.com> -------------- next part -------------- An embedded message was scrubbed... From: Christopher Hegarty - Sun Microsystems Ireland Subject: Re: URLEncodedQueryString Date: Mon, 16 Jul 2007 15:29:38 +0100 Size: 4204 Url: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070716/3acba6a6/attachment.nws From Michael.McMahon at Sun.COM Mon Jul 16 09:35:58 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Mon, 16 Jul 2007 17:35:58 +0100 Subject: [Fwd: Re: URLEncodedQueryString] Message-ID: <469B9E6E.1010303@sun.com> -------------- next part -------------- An embedded message was scrubbed... From: Michael McMahon Subject: Re: URLEncodedQueryString Date: Mon, 16 Jul 2007 16:44:43 +0100 Size: 5424 Url: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070716/0ae302a7/attachment.nws From Michael.McMahon at Sun.COM Mon Jul 16 09:36:24 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Mon, 16 Jul 2007 17:36:24 +0100 Subject: URLEncodedQueryString In-Reply-To: <469B805C.3050703@sun.com> References: <469B5F42.1080100@sun.com> <469B805C.3050703@sun.com> Message-ID: <469B9E88.50704@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > Questions (Sorry, of this has come up before): > 1) Why have overloaded versions of toString and parse. Why not one > method called setSeparator? We need to support both separator types in the same input strings. Though I thought that the original separators had to be preserved, but it seems this is not the case. So, it might be possible to allow both in input strings but use a setSeparator() method to determine which to use for output. > 2) Does getParameterNames return multiple entries for multiple name > value pairs. I think not. No, it shouldn't. > 3) Do we really need removeParameter. Isn't this the same as > setParameter(name, null)? Yes, it is the same. We could remove removeParameter. > comments: > I'll let Richard comment on the following ones. > Class Description > 1) "This class provides constructors for creating..." > This should be 'methods' or static/factory methods. > > I think you should probably also inline links to the methods. I > presume they are create & parse. > > 2) I would make ", methods for creating, retrieving, updating and..." a > new sentence. "Methods for creating,..." > > 3) I think that the code samples in the class description should follow > the java coding conventions. > > http://java.sun.com/docs/codeconv/html/CodeConventions.doc7.html#682 > > For example, the following blank spaces should be removed: > > URI uri = new URI( "http://java.sun.com?forum=2" ); > UrlEncodedQueryString queryString = new UrlEncodedQueryString( uri ); > System.out.println( queryString.getParameter( "forum" )); > > URI uri = new URI("http://java.sun.com?forum=2"); > UrlEncodedQueryString queryString = new UrlEncodedQueryString(uri); > System.out.println(queryString.getParameter("forum")); > > Similar for other code examples. > > Method description: > 1) Both parse methods start with "This constructor...". -> method. > 2) getParameterValues. returns a List not an array. The method > description also needs to be updated. > 3) getParameterMap. Same as 2) > 4) How does setParameters(java.lang.String) handle Separators? > 5) ditto for appendParameters. > 6) apply(URI, UrlEncodedQueryString.Separator). 'Separator' in the > parameter list should start with lowercase 's'. > > -Chris. > > > > Michael McMahon wrote: >> I have updated the CCC request for this, and would like >> to finalize it this week. >> >> Can I get comments on it please? >> >> The apidocs can be seen at >> http://oldsunweb.ireland/~mm72272/urlencodedquerystring/ >> >> Thanks >> Michael. From richard at kennardconsulting.com Wed Jul 18 02:19:00 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Wed, 18 Jul 2007 19:19:00 +1000 Subject: URLEncodedQueryString In-Reply-To: <469B9E88.50704@sun.com> References: <469B5F42.1080100@sun.com> <469B805C.3050703@sun.com> <469B9E88.50704@sun.com> Message-ID: <469DDB04.5010401@kennardconsulting.com> Michael, Thanks for everybody's input! I will only reply to those points that need further discussion. I'll post a new version with the other changes people brought up. > We need to support both separator types in the same input strings. Though I thought that > the original separators had to be preserved, but it seems this is not the case. We could change the design to preserve separators, however it would significantly complicate the class for no appreciable gain (eg. you would have to allow clients to say which separator they wanted when appending new parameters, have to keep those in a separate Map, etc). 99% of the time people are just going to use &'s, I suspect. > use a setSeparator() method to determine which to use for output. We used to do this in a previous version. Someone (Alan?) pointed out it was confusing because it wasn't clear whether the setSeparator() applied to just output or also while parsing. It was advised moving it to a parameter on toString() made this clearer. >> 3) Do we really need removeParameter. Isn't this the same as >> setParameter(name, null)? > Yes, it is the same. We could remove removeParameter. We could also remove String.contains() in favour of String.indexOf() != -1, but I think the same argument applies (eg. clarity of API). > Will the result of getParameterMap preserves the name order? Yes. It returns a LinkedHashMap. > the order of (different named) parameters does not matter. It does not matter for those APIs that return a Map (eg. the Servlet API). However unit tests benefit from a consistent ordering, as do client expectations (eg. if I append a parameter, I generally expect it to appear on the end). It is unclear whether semantically two query strings with the same parameters but in different orders should be considered the same. At the moment I (deliberately) return false for that. Should I maybe return true instead? Regards, Richard.