HW: https://gist.github.com/bridgpal/3e377a9dea50c1cad82a
http://jsfiddle.net/eTcvF/3/ (better solution)
https://developers.google.com/speed/libraries/devguide grab snippets from the google dev website.
//for jQuery: <script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.1/jquery.min.js"></script>
//if you're hosting from localhost, you'll need to add http to the src link.
//<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.10.1/jquery.min.js"></script>The .ready() method can only be called on a jQuery object matching the current document, so the selector can be omitted.
The .ready() method is typically used with an anonymous function:
$(document).ready(function() {
// Handler for .ready() called.
});
Which is equivalent to calling:
$(function() {
// Handler for .ready() called.
});
If .ready() is called after the DOM has been initialized, the new handler passed in will be executed immediately.
cmd option j (mac) or ctr shift j while in chrome browser to open up console.
When you make your request to a server that is JSONP enabled, you pass a special parameter that tells the server a little bit about your page. That way, the server is able to nicely wrap up its response in a way that your page can handle.
Say you're on domain abc.com, and you want to make a request to domain xyz.com. To do so, you need to cross domain boundaries, a no-no in most of browserland.
The one item that bypasses this limitation is <script> tags. When you use a script tag, the domain limitation is ignored, but under normal circumstances, you cant really DO anything with the results, the script just gets evaluated.
Enter JSONP. When you make your request to a server that is JSONP enabled, you pass a special parameter that tells the server a little bit about your page. That way, the server is able to nicely wrap up its response in a way that your page can handle.
For example, say the server expects a parameter called "callback" to enable its JSONP capabilities. Then your request would look like:
http://www.xyz.com/sample.aspx?callback=mycallback Without JSONP, this might return some basic javascript object, like so:
{ foo: 'bar' } However, with JSONP, when the server receives the "callback" parameter, it wraps up the result a little differently, returning something like this:
mycallback({ foo: 'bar' }); As you can see, it will now invoke the method you specified. So, in your page, you define the callback function:
mycallback = function(data){
alert(data.foo);
};
And now, when the script is loaded, it will be evaluated, and your function will be executed. Voila, cross-domain requests!
It is also worth noting the one major issue with JSONP: you lose a lot of control of the request. For example, there is no "nice" way to get proper failure codes back. As a result, you end up using timers to monitor the request, etc, which is always a bit suspect. The proposition for JSONRequest is a great solution to allowing cross domain scripting, maintaining security, and allowing proper control of the request.
The only way to load the data securely, would be to load it through a proxy on the server, and do validation in the proxy before letting the jsonp data through to the browser.
ex.
http://omdbapi.com/?s=star%20wars
http://omdbapi.com/?s=star%20wars&callback=movies
Homework for tonight: https://github.com/aikalima/memory_template_lab