import java.util.ArrayList;
import java.util.Arrays;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
import java.net.URLEncodedQueryString;
import java.net.URLEncodedQueryString.Separator;
/**
* Unit tests for URLEncodedQueryString
*
* @author Richard Kennard
* @version 1
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 UriBuilder plans 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
ft-gregorio-uritemplate-01.txt
[2]
https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/core/UriInfo.html
Richard Kennard wrote:
Michael (Paul? Marc?),
Looking at the JSR311 URIBuilder, and with respect to Mark
(Reinhold)'s concerns, I actually don't think there is much of an
o
out it is at
http://blogs.sun.com/sandoz/entry/building_uris
The javadoc for the proposed UrlEncodedQueryString is attached in a
zip file
Thanks,
Michael.
--
Richard Kennard | Principal | Kennard Consulting
0402 629 952
http://www.kennardconsulting.com
the named parameter has, or..."
How about returning an empty list if the parameter does not exist?
Similar to getParameterNames, "an empty Iterator if there are no
parameters"
Also, typo in @returns
"an List of String objects..." -> "a List
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
Michael,
Please find a new version of UrlEncodedQueryString at:
https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=20545&forumID=1463
Changes include:
1. JavaDoc changes
2. Changed String[] to List
3. Uppercased enums
Basically, everything you asked for EXC
Michael,
Though I think we should stick with the uppercase convention.
Agreed.
What are you suggesting here?
Nothing different to what I have been saying before. HTML requires us to
have the 'multi-valued return' feature, but I think if the API looks like...
class UrlEncodedQueryString
Michael,
Given that I sort of disagree with both these comments, should I just
take it that this is what the CCC wants and make the changes anyway?
My disagreements would be:
1. Overkill or not, surely defining an enum is more explicit, more
type-safe and a generally stricter way of doing th
:
Richard Kennard <[EMAIL PROTECTED]> writes:
Dear All,
Please find the latest version of URLEncodedQueryString at...
https://jdk-collaboration.dev.java.net/
[snip]
Thanks again for all your help, and I look forward to hearing from you,
Hi Richard,
a small meta-c
Michael, Alan,
Please find a new version of UrlEncodedQueryString up at:
https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=20206&forumID=1463
Changes include:
1. Renamed to UrlEncodedQueryString instead of URLEncodedQueryString
2. Removed use of java.net.UR
Michael,
I just thought I'd tackle this point in detail...
So, this means that an '&' embedded in a parameter could not be
recognised when parsing
I don't think you can have an 'embedded & in a parameter' in any
meaningful sense. You'd have to encode it (as %26) or else it would be
recognised
Michael,
>> 1) java.net.URL is discouraged... I would agree with Alan on this.
Fair enough: I shall remove those methods.
Can you confirm you want the naming convention changed to Url? It's just
that everything else in the package uses uppercase URL (for legacy
reasons, I'm sure). Note that t
Alan,
Thanks for sticking with me - your comments and support have definitely
improved my code, and I am grateful to you as a result.
I have updated the version at...
https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=20129&forumID=1463
...to include:
a)
Alan,
I read some distinct 'themes' into your last e-mail. Please permit me to
respond to the 'themes', rather than your exact points:
1. java.net.URL
You said:
'I would suggest ignoring java.net.URL completely... is parse(URL)
needed? ... is apply(URL) needed? ... I believe naming conventi
Dear All,
Please find the latest version of URLEncodedQueryString at...
https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=20098&forumID=1463
Changes include:
1. Static factory methods and a private constructor
2. getParameterMap returns a copy of the Map
3. M
Michael,
Do you know if it makes much (or any) difference to JSP applications
whether objects are created by constructor or by static factory method.
Not really. A lot of the focus on JSPs has already gone from this class (since
we moved it from URIBuilder to URIQueryString). It will now main
Alan,
Thanks for your continued support.
I find the 'static factory method' approach interesting, but I'm a little confused. You cite 'being able to return a subclass' as an advantage.
However, you also recommend a private constructor and classes with private constructors can never be subclasse
-urlencoded' query string.
Regards,
Richard.
Alan Bateman wrote:
Richard Kennard wrote:
:
So, can we agree a regular class is better than a utility class?
That seems reasonable to me. I just suggested thinking about a utility
class given that this is mostly about manipulating a map of
p
21 matches
Mail list logo
