See below, thanx (want to be my Java tutor?)
> > [CODE]
> > cookieArray = request.getCookies();
[quoted text clipped - 88 lines]
> expecting the request.getParameter invocations to return? Where have you
> set those parameters?
request.getParameter("message") is set when the user enters something
into the text field called "message" and submits it by clicking the
"Send" button. The nickname was not originally set by anything and
needed to be added later, but I found a super-simple way of handling
that: a form hidden element called "nickname" - duh! *sigh*
> Are you trying to get back what you put in the request with setAttribute
> when you call getParameter ?
Yes, because I need to have the value of "message" changed only when
the user clicks the "Quit" button, because the value of "message" is
"Quit", but it needs to be "/q", however, I can't display "/q" as a
button.
> When you click the "Send" button does this make send.length() > 0? When
> you click "Quit" button does this make quit.length() > 0? Is it possible
> that both could be true at the same time?
No, when you click the "Send" button then send.length > 0, same with
"Quit". Because both will exist upon form submission.
> When you say "when viewing the contents via out" do you mean the output
> on System.out, or the values printed on out (the text written to the page)?
I'm just using debugging techniques via out to see what message is and
what nickname is, to see what's going on. Out = the implicit Servlet
property "out".
> It looks like you are trying to combine logic for handling people
> submitting messages and quitting in one place, is that correct?
Yes. Like I said, I got the nickname part figured out, and the message
part figured out, but the quitting portion has to be handled
differently and it works now:
[CODE]
if (hasSubmittedMessage && send.length() > 0) {
// SEND MESSAGE DIRECTLY TO MessageProcessor AVOIDING ANY ISSUES
WITH URL DATA SCRAPING INVOLVING QUERY STRINGS
mp = new MessageProcessor(request, response);
mp.process();
} else if (hasSubmittedMessage && quit.length() > 0) {
try { // USING NEW VERSION OF URLEncoder.encode() THAT REQUIRES
try{} BLOCK DUE TO NEW 2ND PARAMETER OF ENC-TYPE
// HTMLRetriever WORKS HERE INSTEAD OF USING request.setAttribute()
I HAVE NO IDEA WHY
retriever = new HTMLRetriever(ChatGlobals.SERVLET_SELF +
"/ppowell.ChatServlet?message=" +
URLEncoder.encode("/q", "UTF-8") +
"&nickname=" +
URLEncoder.encode(cookie, "UTF-8")
);
String junk = retriever.getHTML();
} catch (UnsupportedEncodingException uee) {
errorMsg += "Error involving message submittal: " + uee.toString();
} catch (Exception e) {
errorMsg += "Unknown error: " + e.toString();
}
}
[/CODE]
I simply can't alter request from request.getParameter("message") = ""
to request.getParameter("message") = "/q" (when you click the "Quit"
button and there is no message of course submitted) because I simply
don't know how.
Phil
> James
James Westby - 29 Jan 2006 12:31 GMT
[snip]
>>It looks like your problem is that the
>>
[quoted text clipped - 10 lines]
> needed to be added later, but I found a super-simple way of handling
> that: a form hidden element called "nickname" - duh! *sigh*
Good solution. Doesn't this allow the userto change their nickname to be
anything that they want with a little work? Are you OK with this?
[snip]
>>It looks like you are trying to combine logic for handling people
>>submitting messages and quitting in one place, is that correct?
[quoted text clipped - 22 lines]
> );
> String junk = retriever.getHTML();
You don't need this unused varible. If you just have
retriever.getHtml() there is an implicit cast to void. It's a good idea
to avoid unused variables, as you can make mistakes later on if you have
them lying around.
> } catch (UnsupportedEncodingException uee) {
> errorMsg += "Error involving message submittal: " + uee.toString();
[quoted text clipped - 8 lines]
> button and there is no message of course submitted) because I simply
> don't know how.
[snip]
Yeah, you can't alter it. So in the above code you're creating a new
request with the parameters you want. A slightly better way might have
been to have two methods on your servlet, or two servlets, one for
"Submit", and one for "Quit", that way they can be handled independently.
James