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
Some other minor comments on the last draft.
- Michael.
Class intro docs.
1. In the section entitled "Multivalued parameters" the list refers to
getParameterValue()
This should be getParameter()
2. The first reference to "(ampersand and semicolon)" should inlcude the
actual symbols
th
Richard Kennard wrote:
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...
clas
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
Richard Kennard wrote:
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
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
The CCC request has received initial approval,
which simply means that the API change is accepted in principle.
But, we need to finalize the specification and submit it to the CCC
for final approval.
Due to the (large) amount of discussion that has already
taken place, I don't anticipate that thi
Richard Kennard <[EMAIL PROTECTED]> writes:
>
> Dalibor,
>
> Fair point. I am only following the original advice of the Peabody
> initiative to use http://jdk-collaboration, and the more recent advice
> of the OpenJDK project to use the net-dev mailing list.
>
> If there is a new preference I
Dalibor,
Fair point. I am only following the original advice of the Peabody
initiative to use http://jdk-collaboration, and the more recent advice
of the OpenJDK project to use the net-dev mailing list.
If there is a new preference I am happy to switch to that?
Richard.
Dalibor Topic wrote:
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-comment: URLs
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
Richard Kennard wrote:
Michael,
I just thought I'd tackle this point in detail...
Here we agree! And with the current version of the code, this works...
URLEncodedQueryString queryString =
URLEncodedQueryString.create();
queryString.setParameter( "a", "x&y" );
queryString
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
Richard Kennard wrote:
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
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
Richard Kennard wrote:
What we have left appear to be some fairly small details. If I may
summarise, you are saying...
Yes, I think that is true.
1) java.net.URL is discouraged, therefore we shouldn't support it in
our API nor follow its naming convention (even though we'll sit
alongside it
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)
Richard Kennard wrote:
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
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
Richard Kennard wrote:
:
An alternative approach would be to expose a COPY of the internal Map,
let the user modify it, and then introduce a setParameterMap method to
re-set it. However, the problem there is that, internally, it is
important the Map is a LinkedHashMap - so that it maintains th
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
Richard Kennard wrote:
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 construct
Richard Kennard wrote:
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 construct
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
Richard Kennard wrote:
Alan,
Thanks for your prompt reply! I appreciate you keeping this moving.
1. I would like to postpone the issues of method chaining and URI/URL
creation to another discussion, if that's okay.
2. So what we are debating between here is...
public UrlQueryString {
Alan,
Thanks for your prompt reply! I appreciate you keeping this moving.
1. I would like to postpone the issues of method chaining and URI/URL
creation to another discussion, if that's okay.
2. So what we are debating between here is...
public UrlQueryString {
private UrlQueryStrin
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 parameters.
Some aspects of the builder pattern are probably useful here
28 matches
Mail list logo
