jQuery getJSON call not returning desired arguments?

Question

I searched for a related topic in jQuery, but I didn't see any method to solve my problem.

$(document).ready(function(){
    $("#inputForm").submit(function(event){
        $(":text").each(function() {
            var inputText = $(this).val();
            var userList = [];
            var weblink = 'http://test.com';

            // problem is from here.
            $.getJSON(weblink, function(data){
                alert(weblink); // this statement doesn't show up
                $.each(data, function(entryIndex, entry){
                    userList.push(entry['from_user']);
                });
            });
            alert(userList);
        });
     });
});

There are 3 problems here:

1. Why doesn't the first alert('weblink') doesn't show up?
2. Why this code can't get the json data from website?
3. The goal of this code is to get the from_user tag from json file and store into userList array.

The variables in "$.each(data, function(entryIndex, entry){" statement, the function have two input parameters one is entryIndex and other is entry. I am wondering what these parameters are for and how to use them?.

Can anyone help me solve this problem. I have been stock in here for one day. Thank you very much.

Doubly

have you checked what you are returning is valid json? – Boots

Answer 1

A couple of issues there:

1. getJSON does an ajax request. Ajax requests are subject to the Same Origin Policy. Unless your page is loaded from http://test.com (or a couple of other caveats), it won't work. You're probably looking for JSON-P (which jQuery also supports), provided the server supports it.

2. getJSON, like all ajax requests, is asynchronous by default, so your second alert (with the user list) will happen before the request completes. Although you can make ajax requests synchronous, it's a very bad idea (locks up the UI of most browsers during the request). Instead, just use the user list after you've received it in the callback, rather than trying to use it in the function calling getJSON.

Edit: You've said below that you're trying to use the Twitter search API. That API does support JSON-P, so if you use JSON-P to do your request, it should work. e.g.:

$(document).ready(function(){
    $("#inputForm").submit(function(event){
        $(":text").each(function() {
            var inputText = $(this).val();
            var userList = [];
            var weblink = 'http://search.twitter.com/search.json?q=&ands=google';

            // problem is from here.
            $.ajax({
                url:        weblink,
                dataType:   "jsonp", // <== JSON-P request
                success:    function(data){
                    alert(weblink); // this statement doesn't show up
                    $.each(data.result, function(entryIndex, entry){ // <=== Note, `data.results`, not just `data`
                        userList.push(entry['from_user']); // <=== Or `entry.from_user` would also work (although `entry['from_user']` is just fine)
                    });
                    alert(userList); // <== Note I've moved this (see #2 above)
                }
            });
        });
     });
});

...but surely you don't want to do that for each text field in the form?

Here's a live example but without a form (and only doing one request, not a request for each field).

Reyreyes

Actually, the website is Twitter Search API. – Doubly

@Jimmy: Unless your page is being loaded from search.twitter.com, then, you can't request that data via ajax (because of the SOP). See the link for more. But I bet Twitter offers a JSON-P interface you could use. In fact, a quick search on "twitter json-p interface" suggests that it does. :-) – Reyreyes

@Jimmy: In fact, that specific API page supports JSON-P, so you just have to change your call (and deal with the second issue). Updated with example. – Reyreyes

"locks up the UI of most browsers during the request" hasn't been true for years. Synchronous is fine. – Conscription

@Tomalak: Things are a bit better now, but only a bit (and only for completely up-to-date IE users, and we know there are a LOT of IE users who aren't, usually large government and corporate ones). But even in modern browsers, it completely locks up the page. You can't select text. You can't scroll. You can't do anything on that tab. Synchronous requests are not only a bad idea, they're also completely unnecessary. – Reyreyes

@T.J. The above code works for me however I did notice that the from_user object is located under an array of results so you'd probably want to do something like this $.each(data.results, function (i, e) { userList.push(e.from_user); }); unless there is something I don't know about accessing variables. – Lemuelah

@T.J. Crowder One more question, how can I check the data is correct or not by alert ? Or other way? – Doubly

@Jimmy: I'm afraid I don't understand the question. – Reyreyes

@Nicky: Thanks, I have to admit I didn't even look at the data. But you're right, it's the data.results one wants. Updated. – Reyreyes

@T.J. Crowder I mean that cause the asynchronous problem, how can I check the data form JSON is correct or not? – Doubly

@TJ: "Synchronous requests are unnecessary" is a red herring. Asynchronous ones vastly increase code complexity for a robust and fail-proof system. – Conscription

@Jimmy: Look in your debugger console for the response contents (say, Firebug or Chrome Developer Tools). Copy/paste it into JSONLint to validate it. – Conscription

@Tomalak: I don't think user experience is a red herring in the least. Code need not be substantially more complex, not if you really understand JavaScript (that's not a dig). Asynchronous requests are just the same as the event-driven programming you have to do anyway to respond to the user. – Reyreyes

@Jimmy: "...how can I check the data form JSON is correct or not?" jQuery will check that it's proper JSON-P (to the extent it can). At that point, you just look at the object structure you've received and make sure it looks like what you were expecting. – Reyreyes

@TJ: I don't think Javascript specifically has much to do with it: to correctly and robustly handle concurrent, asynchronous requests within the scope of your application clearly involves far more complex code than simple, procedural, non-concurrent synchronous requests, I think. Especially when it comes to request error handling! Does a failure of request 1 affect request 2? How? When? In what way? Ewness. – Conscription

@Tomalak: You keep saying it's much more complicated. I have to say that that just is not my experience. Re your other points: You're arguing for serializing requests, there, not making them synchronous. That's a different thing. You certainly don't want to fire off an overlapping request if it depends on the results of the first one! I mention JavaScript because it has features that make event-based stuff much, much easier than some other languages. – Reyreyes

@TJ: Perhaps your code isn't very robust then :P And if you were to serialise requests, making them synchronous is the obvious way to do that. Take advantage of the fact that lines of code are executed in a serialised fashion already. – Conscription

@Tomalak: Re robustness: Oh come on, no need for throwing around statements like that. Re the other: I haven't needed to do much serializing of requests, but when I have, I've preferred to serialize them rather than make the user wait. You clearly don't have a problem with using them. So good, I'm glad you have a good result with them. I think they're an unnecessary impact on the user experience. Best, – Reyreyes

@TJ: Please read the ":P" along with the rest of the comment. Anyway, so how do you implement your serialisation? Dispatch queue? – Conscription

@TJ: I'm just trying to ascertain whether there are less complex ways to serialise asynchronous requests that I've missed up to now (that might tip the scales in balance with the alleged disruption of synchronous requests to the user experience). "It's just fallen out naturally from the application logic" seems to me like a pretty rare use case on the web, where requests are most frequently initiated by a user click or action. Requests don't have to be strictly dependent on each other for concurrency to be a problem. – Conscription

@TJ I wrote a code copy from you. But still doesn't show the second alert. And the other problem is when I use the form data. The first alert still doesn't show up...it's really weird. The code is below, can you help me. Javascript Code, HTML Code . Thank you. – Doubly

Answer 2

Just add to link

&callback=?

or

?callback=?

(if it's first and only GET variable) This will make your call into JSONP call, which doesn't have problems with Same Origin Policy.

Assign

IE sets catch on ajax. add this before getJson. $.ajaxSetup({ cache: false }); – Mispickel

Answer 3

Not sure but doesn't it require get arguments? Try this:

$.getJSON(weblink, {}, function(data){

Impassible

Answer 4

Are you using MVC platform? Apparently, by default MVC 2.0 blocks GET requests to actions that return a JsonResult. Check out:

http://mhinze.com/2010/04/13/json-hijacking-in-asp-net-mvc-2/

I had the same problem whilst upgrading an existing application (written in MVC v1) that used .getJSON calls to pull data from MVC Controller to View (via jquery/javascript) & could not figure out why they did not work I tried different versions of jquery with no luck, then I found the above link. I changed to POST instead (and also changed slightly how the data was sent from the Controller - used Dictionary ) and got it working - finally!!

Good luck! JayD

Peccadillo

Answer 5

I would like to add another reason why jQuery.getJSON() might not response as expected in a developing environment under IIS for Windows.

Following all the procedures provided here, I was not able to get any data from a *.json file, only if I changed the extension to *.js, the response status returned

{"status"="404", "statusText"="Not Found"}

Then I remembered that with IIS there are some MIME/Types that are not specified. Adding MIME/Type application/json for files with extension .json solved my problem.

For information how to add MIME/types on iis7.

Cameraman