hought it may be worth revisiting RFE 6306820? All the hard work for this
>> RFE has already been done. There is a solid implementation, approved by 5
>> out of 6 CCC members, and in real-world use for over 4 years:
>>
>>http://java.net/projects/urlencodedquerystring
>
ady been done. There is a solid implementation, approved by 5
> out of 6 CCC members, and in real-world use for over 4 years:
>
>http://java.net/projects/urlencodedquerystring
>
> Can I pique anyone's interests in getting this resolved? It seems an easy
> win.
>
Hi - perhaps
for over 4 years:
http://java.net/projects/urlencodedquerystring
Can I pique anyone's interests in getting this resolved? It seems an easy
win.
Regards,
Richard.
--
View this message in context:
http://old.nabble.com/UrlEncodedQueryString-%28RFE-6306820%29%3Aa-painless-addition--tp32
Max,
Sure, I will make that change.
Alan and Michael decided against Serializable, on balance.
Regards,
Richard.
--
View this message in context:
http://www.nabble.com/Resurrect-UrlEncodedQueryString-%28RFE-6306820%29--tp22735890p22736814.html
Sent from the OpenJDK Networking Development
Hi Richard
Sorry, I haven't noticed the words. However, it might be clearer if the
first sentence in the doc says "Represents a www-form-urlencoded query
string containing an ordered list of parameters".
Something else:
Is it worthwhile to make the class Serializable?
Thanks
Max
kennardconsul
this message in context:
http://www.nabble.com/Resurrect-UrlEncodedQueryString-%28RFE-6306820%29--tp22735890p22736667.html
Sent from the OpenJDK Networking Development mailing list archive at Nabble.com.
this message in context:
http://www.nabble.com/Resurrect-UrlEncodedQueryString-%28RFE-6306820%29--tp22735890p22736664.html
Sent from the OpenJDK Networking Development mailing list archive at Nabble.com.
this message in context:
http://www.nabble.com/Resurrect-UrlEncodedQueryString-%28RFE-6306820%29--tp22735890p22736661.html
Sent from the OpenJDK Networking Development mailing list archive at Nabble.com.
this message in context:
http://www.nabble.com/Resurrect-UrlEncodedQueryString-%28RFE-6306820%29--tp22735890p22736659.html
Sent from the OpenJDK Networking Development mailing list archive at Nabble.com.
Is "?a=b&c=d" different from "?c=d&a=d" ?
kennardconsulting wrote:
> Guys,
>
> I have been prodded to try and resurrect the work we did on
> UrlEncodedQueryString. The story so far is...
>
> 1. Michael, Alan and I spent 18 months working on i
ied object with this UrlEncodedQueryString for equality.
>
> Returns true if the given object is also a UrlEncodedQueryString and the two
> UrlEncodedQueryStrings have the same parameters. More formally, two
> UrlEncodedQueryStrings t1 and t2 represent the same UrlEncodedQueryString i
Yes. From the JavaDoc for .equals():
---
Compares the specified object with this UrlEncodedQueryString for equality.
Returns true if the given object is also a UrlEncodedQueryString and the two
UrlEncodedQueryStrings have the same parameters. More formally, two
UrlEncodedQueryStrings t1 and
Guys,
I have been prodded to try and resurrect the work we did on
UrlEncodedQueryString. The story so far is...
1. Michael, Alan and I spent 18 months working on it until we were all
pretty happy with it
2. Everyone on the CCC except Mark Reinhold signed off on it
3. Mark had reservations on
added that takes a UrlEncodedQueryString
2) We remove the apply() methods from UrlEncodedQueryString because you
build URIs now through UriBuilder.
3) Most methods in UrlEncodedQueryString need to be renamed. The word
Parameter needs to be removed from all
of them. So, appendParameter
Marc,
> The builder is strictly that, a builder, so I'm not sure if it makes
sense to add read capabilities to it
Agreed. I actually don't think these two classes (UriBuilder and
UrlEncodedQueryString) overlap much. How about I propose this as a
direction:
1. JSR-311's U
e building capabilities of UriBuilder
(probably use that name also)
with the retrieval/query manipulation capabilities of
UrlEncodedQueryString.
I think the method names from UrlEncodedQueryString will have
to change though
eg addParameter() would need to be addQueryParameter()
he future
2) then we combine the building capabilities of UriBuilder (probably
use that name also)
with the retrieval/query manipulation capabilities of
UrlEncodedQueryString.
I think the method names from UrlEncodedQueryString will have to
change though
eg addParameter() would n
that it could extend the java.net class in the future
2) then we combine the building capabilities of UriBuilder (probably use
that name also)
with the retrieval/query manipulation capabilities of
UrlEncodedQueryString.
I think the method names from UrlEncodedQueryString will have to
Marc,
Thanks for your reply.
> The JSR 311 UriBuilder has methods for scheme, host, port and
userInfo. We did have authority too but removed it since its a composite
of some of the others.
Right, sorry - I missed those when I was looking at the JavaDoc.
> I think it would make sense for the
nd a specialized subclass, and a standalone class - and preferred
the latter, hence where we are with UrlEncodedQueryString today.
What do you think?
I think it would make sense for the JSR 311 class to extend a
generalized java.net class since we'd want to add support for URI
templa
The
java.net team and I tried two ways - a generalized superclass and a
specialized subclass, and a standalone class - and preferred the latter,
hence where we are with UrlEncodedQueryString today.
What do you think?
Regards,
Richard.
Paul.
If it is at all specific it is focused on the
r isn't concerned
with parsing and retrieving and modifying, and UrlEncodedQueryString
isn't concerned with UriTemplates.
Regards,
Richard.
Michael McMahon wrote:
We have been asked by the CCC to go back and reconsider the design of
the proposed
UrlEncodedQueryString class/API and to co
ilder isn't concerned with
parsing and retrieving and modifying, and UrlEncodedQueryString isn't
concerned with UriTemplates.
Regards,
Richard.
Michael McMahon wrote:
We have been asked by the CCC to go back and reconsider the design of
the proposed
UrlEncodedQueryString c
1 may want to use
java.net.UrlEncodedQueryString internally, I don't see how the two
classes could effectively merge, because UriBuilder isn't concerned with
parsing and retrieving and modifying, and UrlEncodedQueryString isn't
concerned with UriTemplates.
Regards,
Richard.
Richard Kennard wrote:
Chris,
Thanks for your feedback. And actually, picky is good! I much prefer
picky feedback to no feedback at all.
I have updated the JavaDoc with your suggestions:
https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=20922&forumID=1463
cky) comments:
1) "Thread Safety
Instances of UrlEncodedQueryString are not not synchronized."
Typo: "not not".
I would expand this a little. Maybe taking wording similar to
java.util.HashMap:
"Note that this implementation is not synchronized. If m
Some initial (picky) comments:
1) "Thread Safety
Instances of UrlEncodedQueryString are not not synchronized."
Typo: "not not".
I would expand this a little. Maybe taking wording similar to
java.util.HashMap:
"Note that this implementation is not
Michael,
I have further updated URLEncodedQueryString to incorporate everybody's
JavaDoc feedback:
https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=20908&forumID=1463
Hoped to hear from you soon,
Richard.
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
ot;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(
esn't seem right.
3. public static UrlEncodedQueryString create(Map>
pMap)
"Creates a UrlEncodedQueryString from the given Map. The order the
parameters are created in corresponds to the iteration order of the Map."
For a multivalued parameter, the order of these values shoul
he 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 queryS
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(&q
--- Begin Message ---
1. How about setParameters(String name, List values) so that
I can set a multivalued parameter in one call?
2. Why undefined result when input string is not a url-encoded query
string? Why not throw an Exception?
3. public static UrlEncodedQueryString create
(Map
34 matches
Mail list logo
