Your SlideShare is downloading. ×
Jquery Ajax
Jquery Ajax
Jquery Ajax
Jquery Ajax
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Jquery Ajax

675

Published on

JQuery Ajax is client side framework that consists of a set of methods that raise a request asynchronously to the server.

JQuery Ajax is client side framework that consists of a set of methods that raise a request asynchronously to the server.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
675
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Ajax (jquery)One of the biggest advantages that Ajax has in web pages is that it can access information onthe server without having to reload the web page. This means that to retrieve or update onesmall piece of information only that information needs to be passed to and from the serverinstead of having to redownload the entire web page.There are two ways that Ajax can access the server. These are synchronous (where the scriptstops and waits for the server to send back a reply before continuing) and asynchronous (wherethe script allows the page to continue to be processed and will handle the reply if and when itarrives).Processing your request synchronously is a bit like reloading the page but with only therequested information having to be downloaded instead of the entire page. This method istherefore somewhat faster than not using Ajax since the information to be downloaded shouldbe significantly smaller and hence faster to retrieve than downloading the entire page overagain. It does however still require that your visitor wait for the download to occur. While yourvisitors are used to having to wait for entire web pages to download, they are not used tohaving to wait while interacting with a web page for any significant time and so unless theinformation you are requesting is particularly small so that it can be downloaded extremelyquickly you run the risk of alienating visitors who may have been quite happy with a longer waitto download the entire page.Processing asynchronously avoids the delay while the retrieval from the server is taking placebecause your visitor can continue to interact with the web page and the requested informationwill be processed with the response updating the page as and when it arrives. For largerrequests where the response will have a noticeable delay that delay possibly will not be noticedby your visitors because they are occupied interacting with fields further down the page. Forresponses that are nearly instantaneous your visitors will not even be aware that a request tothe server was made.The preferred way to use Ajax therefore is to use asynchronous calls where ever possible so asto enhance your visitors experience with the web page and to avoid having the Ajax interferewith the operation of the page. Using Ajax asynchronously is so obviously the right way thatAjax should be used that the A in Ajax is actually considered by those who consider AJAX to bean acronym to stand for Asynchronous (although the originator of the term claims that it is notan acronym and the letters therefore dont stand for anything).If asynchronous calls are so much better for your visitors experience of the page thansynchronous calls, why does Ajax provide a way to make synchronous calls at all? Whileasynchronous calls will work 99.9% of the time, there are rare situations where it just doesntmake any sense at all to allow your visitor to continue interacting with the web page until aparticular server side process completes. In many of these cases it may be better to not use
  • 2. Ajax at all and instead just reload the entire page. The synchronous option in Ajax is there forthe small number of situations where you cant use an asynchronous call and reloading theentire page is also inappropriate. There are not many such situations but they do exist and soAjax provides for them.A trap that many beginners may fall into is to use synchronous Ajax calls where asynchronouscalls are more appropriate (as they are most of the time). The reason for this is thatsynchronous calls are easier to understand how the processing works. The thing is thatasynchronous calls actually work exactly the same way except for the processing not waiting forthe response but instead just handling the response when it arrives.The only difference when using asynchronous calls is that you can actually set up multiple Ajaxcalls that overlap with a second call being made before the first has responded. This is whereasynchronous Ajax does become slightly more complicated than synchronous Ajax because youneed to make sure that each Ajax request uses a separate Ajax object rather than reusing thesame object for all your Ajax requests. If you use the same object for multiple asynchronousAjax calls then the response handler will only handle the first response that it receives and willdisregard any subsequent responses. With overlapping Ajax calls with the same object you haveno real way to tell whether the response that gets processed is a response to the first call or thesecond. By using separate objects for each Ajax call you will have a separate response handlerfor each request that will handle toe response from the request made by that object.Using Ajax asynchronously is the better choice for most situations. If you are only making theone Ajax call from the page then it is no different in the way you code it to what you would usefor a synchronous call except for the one parameter that identifies how the call is to beprocessed. With multiple Ajax calls on the same page, the only additional complication is thatyou need to create a separate Ajax object for each request. As the various Ajax libraries will alldo this for you anyway the only time that coding your Ajax to use asynchronous calls will be anydifferent from what you could get away with for synchronous calls is if you are coding all of theJavaScript for the Ajax calls yourself instead of using a library to do it for you.Get or PostWhen you use Ajax to access the server without reloading the web page you have two choices onhow to pass the information for the request to the server. These two options are to use GET orPOST.These are the same two options that you have when passing requests to the server to load a newpage with two differences. The first difference is that you are only requesting a small piece ofinformation instead of an entire web page. The second and most noticeable difference is thatsince the Ajax request doesnt appear in the address bar there is no noticeable difference that yourvisitor will see on their screen when the request is made. Calls made using GET will not exposethe fields and their values anywhere that using POST does not also expose when the call is madefrom Ajax.
  • 3. So how should we make the choice as to which of these two alternatives that we should use?A mistake that some beginners might make is to use GET for most of their calls simply becauseit is the easier of the two to code. The most noticeable difference between GET and POST callsin Ajax is that GET calls still have the same limit on the amount of data that can be passed asapplies when requesting a new page load. The only difference is that as you are only processing asmall amount of data with an Ajax request (or at least thats how you should use it) you are farless likely to run into this length limit from within Ajax to what you are with complete web pageloads. A beginner may reserve using POST requests for the few instances where they do need topass more information that the GET method allows.The best solution when you have lots of data to pass like that is to make multiple Ajax callspassing a few pieces of information at a time. If you are going to pass huge amounts of data all inthe one Ajax call then you would probably be better off simply reloading the entire page sincethere will be no significant difference in the processing time when huge amounts of data areinvolved.So if the amount of data to be passed isnt a good reason to use for choosing between GET andPOST then what should we use to decide which to use? These two methods were in fact set upfor entirely different purposes and the differences between how they work are in part due to thedifference in what they are intended to be used for. This not only applies to using GET andPOST from Ajax but applies to these methods where ever they are used.The purpose of GET is as its name implies - to GET information. It is intended to be used whenyou are reading information to display on the page. Browsers will cache the result from a GETrequest and if the same GET request is made again then they will display the cached result ratherthan rerunning the entire request. This is not a flaw in the browser processing but is deliberatelydesigned to work that way so as to make GET calls more efficient when the calls are used fortheir intended purpose. A GET call is retrieving data to display in the page and data is notexpected to be changed on the server by such a call and so re-requesting the same data should beexpected to obtain the same result.The POST method is intended to be used where you are updating information on the server. Sucha call is expected to make changes to the data stored on the server and the results returned fromtwo identical POST calls may very well be completely different from one another since theinitial values before the second POST call will be different from the initial values before the firstcall because the first call will have updated at least some of those values. A POST call willtherefore always obtain the response from the server rather than keeping a cached copy of theprior response.So rather than choosing between GET and POST based on the amount of data that you arepassing in your Ajax call, you should select between them based on what the Ajax call is actuallydoing. If the call is to retrieve data from the server then use GET. If the value to be retrieved isexpected to vary over time as a result of other processes updating it then add a current timeparameter to what you are passing in your GET call so that the later calls will not use an earlier
  • 4. cached copy of the result that is no longer correct. If your call is going to write any data at all tothe server then use POST.In fact you should not only use these criteria for selecting between GET and POST for your Ajaxcalls. You should use this as the criteria for choosing whether to use GET or POST whenprocessing forms on your web page as well.

×