Jump to content

AJAX and JSON


davej

Recommended Posts

I'm still not clear on how this works. Considering the example here; http://www.w3schools...son/default.asp

{"employees": [{ "firstName":"John" , "lastName":"Doe" },{ "firstName":"Anna" , "lastName":"Smith" },{ "firstName":"Peter" , "lastName":"Jones" }]}

What would you see as the page source if you had the browser receive this from the server with Javascript turned off? In other words Javascript sends the Ajax request to the server for this data but then does not set up a handler. Thanks

Edited by davej
Link to comment
Share on other sites

if Javascript was turned off, there would have been no AJAX request in the first place, and thus no (JSON) response.

Edited by thescientist
Link to comment
Share on other sites

if Javascript was turned off, there would have been no AJAX request in the first place, and thus no (JSON) response.
Well, yes this would only be an artificial test case, but say the Javascript failed to set the handler up. What data actually shows up at the browser? I guess an additional question might be to ask what the Php code that generates the above example data structure would look like. Thanks! Edited by davej
Link to comment
Share on other sites

what's the real question here? I can't what you're actually trying to get at. If you create an AJAX request, but don't set up any sort of a callback (async) or check for readystate manually, (sync) then nothing will happen, either good or bad. You might see something in the console, but there would be no affects to your script/page. If you want to output JSON via PHP, then use json_encode. First you have to be familiar with PHP array syntax though, if you already aren'thttp://www.w3schools.com/php/php_arrays.asphttp://php.net/manual/en/function.json-encode.php

 $array => array(  "employees" => array(    array("firstName" => "John", "lastName" => "Doe"),    array("firstName"=>"Anna", "lastName"=>"Smith"),    array("firstName"=>"Peter", "lastName"=>"Jones")  )); echo json_encode($array);

Link to comment
Share on other sites

What I was interested in was what the raw data looks like. So will the browser ignore it because it doesn't start with <html>? Or will the browser display it? Or will the browser report an error?

Edited by davej
Link to comment
Share on other sites

The browser will interpret it based on the headers sent from the server. If you send a "text/html" content-type header then any <tags> won't be printed and they'll be added to the DOM tree instead. If you send it with text/plain or text/javascript the browser will print the content as it is.

Link to comment
Share on other sites

What I'm interested in is what the raw data looks like. Will the browser ignore it because it doesn't start with <html>? Or will the browser display it? Or will the browser report an error?
If you've requested it with AJAX - none of the above.The raw data is available from the "responseText" property of XMLHttpRequest, once the request is actually performed. Whatever you've written will be available there in exactly the way you wrote it. If you write "<html>", the value of responseText will be "<html>". If you write "{}", responseText will be "{}", etc.It's up to you, within JavaScript, to actually interpret that "{}" to mean either the text "{}", or something else, such as JSON. If JavaScript is not available, you wouldn't send a request to begin with, and if no callback was specified, the response is never interpreted, so whatever you had in the response would have no effect at all.If, from your browser, directly, you open up a PHP file that outputs JSON, what you see will depend on the Content-Type header.
Link to comment
Share on other sites

So Javascript/Ajax issues a POST to the server with an identifier, perhaps a hidden input, which identifies the post as being an Ajax request, and then the server sends a response packet back. When the packet of data arrives at the browser -- how is it identified as being the response to the Ajax XMLHttpRequest ?

Link to comment
Share on other sites

It's impossible to know if a request was sent with AJAX or not because it's an ordinary HTTP request like any other. You could set a request header and look for it on the server-side but people could fool that if they wanted to.

Link to comment
Share on other sites

So Javascript/Ajax issues a POST to the server with an identifier, perhaps a hidden input, which identifies the post as being an Ajax request, and then the server sends a response packet back. When the packet of data arrives at the browser -- how is it identified as being the response to the Ajax XMLHttpRequest ?
No. No identifier or anything like that is sent (at least not transparently; you could send such stuff if you wanted, but there's little point in doing so).When you open up a URL directly in the browser, the browser is doing the same you're doing with an AJAX request - it sends a request and receives raw data from the server (the same data you have in responseText). The difference is that in addition to that, it automatically interprets that raw data in some fashion (HTML, plan text, image, etc.) and displays the interpretation on the screen. How exactly is the data interpreted depends on the Content-Type header of the response. JavaScript doesn't do any interpretation - it simply lets you view the raw data, allowing you to interpret it in whatever fashion you want by whatever criteria you want (not necessarily the Content-Type).

Well... strictly speaking, JavaScript does do one interpretation automatically... the responseXML property contains an interpretation of the raw data as a well formed XML document. But that's still not the same as the interpretations that end up doing something visible to the end user.

Link to comment
Share on other sites

So Javascript assigns a function to receive the next HTTP (port 80) packet that the browser receives, and the request is only good for that single packet.

Link to comment
Share on other sites

So Javascript assigns a function to receive the next HTTP (port 80) packet that the browser receives, and the request is only good for that single packet.
The term is "HTTP response" (which will matter to you if you ever do anything socket or router related), but... essentially, yes.
Link to comment
Share on other sites

The request and the response are coupled, they don't exist without each other. A request always has a response (at least in a non-error situation), and a response always started with a request. Both of them happen on a single connection. When you make a request the browser opens a connection to the server, sends the request, and keeps the connection open waiting for a response. When the server responds it goes through the same connection so the browser knows right there which request the response is for (because they happened in the same connection). After the request is sent the server closes the connection (or eventually it times out and the browser closes it). Anything else that happens outside of that communication chain is up to you. The browser does not do anything with the response data that you haven't told it to do. If you haven't told it to do anything with the response or react to the response in any way, then it won't do anything. It's up to you to listen for the response, validate that it succeeded, get the response data, etc.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...