Programming Microsoft ASP.NET 4 - Dino Esposito [483]
displayDetailsForPlayer(jsonData);
});
The getJSON function appends any input data to the URL as a query string. If the data is not of a primitive type, the function will convert it to a string before appending it to the URL. The request is placed as an HTTP GET request.
Any response is assumed to be JSON and is parsed as such using the global $.parseJSON function. The callback receives the parsed data ready to use.
Getting HTML
A frequent action you might want to perform from a client page is downloading some HTML via a simple GET request. The load function is an instance (as opposed to global) function that you can call over a wrapped set. Here’s the signature of the function:
$(selector).load(url, inputData, succeededCallback)
Note that input data and callback function are optional. In particular, the method is automatically bound to a default callback function that appends the downloaded markup to all elements in the wrapped set. Here’s an example:
var templateType = 1;
$("#panelAdvancedOptions").load("/template.aspx", templateType);
If any callback is provided in the call, it is executed after the default callback. No call is ever attempted if the wrapped set is empty. If the input data is a JavaScript object, the request goes out as a POST instead of a GET.
You are not forced to download the entire content of the provided URL. If the URL contains a white space, anything that follows is interpreted as a jQuery selector. Look at the following example:
$("#panelAdvancedOptions").load("/template.aspx #area_1");
The entire URL content is downloaded, but jQuery then discards everything but the DOM tree selected by the #area_1 expression. When you use load, you should be aware that some tags might be discarded during the parsing process. This typically occurs with tags such as and
Cross-Domain Calls
The biggest difference between making a browser-led request and an Ajax-led request is in what happens after the response has been downloaded. The browser safely processes the response to display it. The script, on the other hand, can potentially make any use of the downloaded response—from building hopefully innocuous mashups to preparing cross-site scripting attacks. For this reason, all browsers implement the Same-Origin Policy (SOP), which means that script-led calls are allowed to hit only the same server that served the current page.
Nobody complained about SOP until Ajax became as popular as it is today. SOP represents a serious limitation for developers of Ajax applications because it prevents you from easily creating mashups and, more in general, to requesting data from a site that lives on a different host or that uses a different protocol. Workarounds have been in the works for years, but we’re still looking for an official standard solution to the issue. W3C has a working draft for something called Cross-Origin Resource Sharing (CORS), which defines a common ground for browsers and Web servers to interoperate and enable applications to perform secure cross-site data transfers. Some browsers currently support CORS to some extent and through different APIs. That will probably be the mainstream approach in the near future.
While waiting for that, you might want to consider other approaches, such as using a server-side proxy, Silverlight or Flash applets and their workarounds to bypass SOP, and leveraging cross-domain enabled HTML tags such as -->