Bear Bibeault wrote:This code:searches for an element with the id myDiv which doesn't exist. So, yeah, nothing happens.
You also need to be consistent with variable names.
Karthik Shiraly wrote:I notice
you areyour code is missing some closing braces. Is it like that in actual code, or just a mistake made here while posting?
Karthik Shiraly wrote:The brace placement is incorrect, because it's changed the logic. Now it's trying to send the XHR from inside the XHR state change function, but that function will never get called until a XHR is sent.
Your previous version seems mostly correct, except for the one missing brace for the if statement.
Yes it can be done, we just have to figure out how.
Anurag Verma wrote:Bear has clearly told whats wrong...check variable names, how about changing xmlhttp to xhttp? Also if the issue is solved, then a small message like "it worked" would be great
Dave Tolls wrote:Learn to use the debugger of whatever browser you are using (Chrome has a good one, IMO).
Bear Bibeault wrote:
Dave Tolls wrote:Learn to use the debugger of whatever browser you are using (Chrome has a good one, IMO).
This. Do it now. Immediately. Before you write a single more line of code.
Otherwise, you are wasting your time.
Then, set a breakpoint in the handler. is it even being called?
And then, stop the madness and use jQuery for your Ajax.
Bear Bibeault wrote:OK, so at the breakpoint, you can examine the results of the various expressions that you are using.
Does the call to fetch the element return what you expect? Does the reference to the response text contain what you expect?
Bear Bibeault wrote:OK, so now look at the network section of the debugger to see what's going wrong.
Bear Bibeault wrote:You're doing it the hard way -- no one does that.
In this day and age, you should be using jQuery or some other library.
In jQuery, this is a single line of code.
What does the debugger say about your request?
Bear Bibeault wrote:It sounds like your page is doing from the servlet's server, why the need for CORS?
But, yes, jQuery. Doing it the hard way isn't a useful exercise, in my opinion.
Bear Bibeault wrote:For the type of thing you are trying to do (just stuff the response into the DOM), you'd want to use the load() method.
Make sure you are using server-relative URLs for your requests.
Mike London wrote:
when all I'm doing is a call like this:
xhttp.open("POST", "http://localhost:8080/AjaxSvr/ajax", true);
Bear Bibeault wrote:
Mike London wrote:
when all I'm doing is a call like this:
xhttp.open("POST", "http://localhost:8080/AjaxSvr/ajax", true);
I'm beginning to think that you don't even read my posts.
Use server-relative URLs when requesting back to the same server.
Mike London wrote:
It's just that you often say "what" to do, but not "how" to do it or give a simple example.
Case in point: Since I need to tell the server I'm using Tomcat, etc., I'm puzzled how I would convert a http://localhost:8080/AjaxSrv/ajax into a server relative path.
I have also experimented, but thus far am getting 404 errors (for example ./AjaxSvr/ajax does not work).
Bear Bibeault wrote:
Mike London wrote:
It's just that you often say "what" to do, but not "how" to do it or give a simple example.
Yup. You'll learn more that way. If there's not enough detail to move forward; ask. But I'm not going to just give you the code.![]()
Case in point: Since I need to tell the server I'm using Tomcat, etc., I'm puzzled how I would convert a http://localhost:8080/AjaxSrv/ajax into a server relative path.
This has nothing to do with Tomcat. A server-relative path, described in the JspFaq, is simply the part of the URL as relative to the server. In other words, drop the path to the server and just leave what's relevant to within the server. In the case of Java web apps, that begins with the context path; in this case /AjaxSvr.
I have also experimented, but thus far am getting 404 errors (for example ./AjaxSvr/ajax does not work).
Anything that starts with a dot is page-relative, and you never want to use that. You'll start with the context path.
Bear Bibeault wrote:Cool, you might still want to read through the JspFaq entires about paths to make sure you understand when to use what type of path.
Does the response now return the expected text?
Bear Bibeault wrote:Why would POST act like a GET? You shouldn't expect it to (and shouldn't code it to do so).
Paul Clapham wrote:POST gives you the 403 return code because your servlet only supports GET. That's what the doGet() method does, it supports the GET method. I leave it to you to figure out how to support POST, but as already pointed out you shouldn't be changing to POST just because you think using GET might be the problem, or (worse) because you want to make a random change to see if it fixes your problem.
I am going to test your electrical conductivity with this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|