For this round of coding, I am focusing on the $.ajax() method. In my present design, my single page web application makes REST calls for many of the UI menu items. For example, a click on the FILE->LOAD menu item triggers a function call to code that retrieves a file from my server. The basic pattern is like this:

// Start spinner
// start logging timer
$.ajax({"url":RestURI,
 "type":"GET",
 "dataType":"json",
 success: function(data) {
 // Do success stuff (parse, format and display)
 // stop logging timer, do logging
 // stop spinnger
 }, /* end success: */

 error: function (req, stat, err) {
 // Do error stuff
 // stop logging timer, do logging
 // stop spinner
 } /* end error: */
});

I have more than 7 code blocks that follow this pattern. Since the success/error/complete callback functions have been deprecated and I need to touch the code anyways, I thought I’d use the newish $.ajax() global events handlers  to clean up my code. The event handlers seem to be a useful place to put common pieces of code that really shouldn’t have been so liberally cut-and-pasted when I wrote the original code.

For each of my ajax code blocks, I put a generous amount of logging in. Maybe this logging should only be needed when writing/debugging the code, but for me, since I spend so little dedicated time on this application, I wanted to keep verbose logging on always to make it real easy for me to debug.

$.ajax logging using Ajax Global Events

The following new block of code is doing my $.ajax logging using Ajax Global Events.

$(document).ajaxSend(function(evt, xhr, settings) {
 console.log(settings.type+" "+settings.url+" Sent");
 start = new Date().getTime();
 // Other logging
});
$(document).ajaxSuccess(function(evt, xhr, settings) {
 console.log(settings.type+" "+settings.url+" Success");
 // Other logging
});
$(document).ajaxError(function(evt, xhr, settings, exc) {
 console.log( settings.type+" "+settings.url+" Failed. "
 +xhr.status+"-"+xhr.statusText);
 // Other logging
});
$(document).ajaxComplete(function(evt, xhr, settings) {
 console.log(settings.type+" "+settings.url+" Complete");
 end = new Date().getTime();
 diff = end - start;
 // Other logging
});

As you can see, the ajaxSend/ajaxSuccess/ajaxError/ajaxComplete events are fired in sequence at the $.ajax() function executes and after the  .done(), .fail() and .compete() callbacks are executed.

The “Other logging” comment represents 2 or 3 lines of code where I put logging information into a user visible menu item (REPORTS->LOG) where I can see even more details without having to open the console window. For me, this effort is a nice clean out some of the logging stuff, to make the application logic a little more visible;  this clears up a bunch of clutter for me.

New-ish .done/.fail/.always Callbacks

Therefore, my $.ajax() code blocks are straighten out to follow the new done/fail/always callbacks. Here’s an example new $.ajax() code block:

// Start spinner
$.ajax({url:RestURI,
 type:"GET",
 dataType:"json"})
 .done( function(data, textStatus, jqXHR) {
 // Do success stuff
 }) /* end done: */

 .fail( function (jqXHR, textStatus, err) {
 // Do error stuff
 }) /* end fail */

 .always( function() {
 // stop spinner
 }); /* End always */

Some things to note: I still put the start/stop spinner function calls inline. I may move this to the global even handlers, but not yet.

Deferred Objects

Also, the done/fail/always call backs follow the new Deferred Object model. This will then let me setup some promise objects to let me address some of the async race conditions I have in my application.

For example, I have a case where I can run FILE->SAVE and then run REPORT->General and the report will produce results before the save was completed. I know how to fix this, but I was looking to use my new ajax code blocks architecture to get some practice with promise objects instead… for next time.

The post $.ajax logging using Ajax Global Events. Re-factoring Single Page Web Application appeared first on JackKozik.com.

For starters, I knew that v1.9 had deprecated many of its old methods. In fact, I learned from the upgrade web page, , that v1.9 comes with a special migration plug-in. I was pleased to see this and used this to address most all of my updating challenages.

For example, $.browser() method was deprecated. The migrate script reported this to me in the Chrome console, as follows:

Chrome console:

With a little digging, I was able to find that I was using an old version of blockUI. When I changed to the new version the warning message went away.

I also got the following warning messages related to type changing and the change to the andSelf() method:

Chrome console:

Again, it took a lot of digging, but I was able to isolate the problem to my tmpl.js script. I was using a really old version. I think with a little more skill on my part, I would better be able to use stack backtraces or some other Chrome tool to find these quicker, but this problem was hard for me to find.

Since I was also using an old version of jQuery-UI, I stumbled upon a couple of breakages triggered by curCSS:

Chrome console:

For some reason, also, the dialog() method wouldn’t display text in the “OK” button and it would always popup at 0.0 (upper left), so I upgraded to jQuery-ui v1.9.2.

One last thing for Updating to jQuery 1.9. I had to change all of my .live() events to .on(). The migration guide clearly covered this.

Here’s an example from my website:

//$('#journal input').live('keydown', function(evt) {
$(document).on('keydown','#journal input', function(evt) {

This was easy to do; I had to do it in 6 different place, and it worked the first time.

Updating to jQuery 1.9 was a little more painful than I would like, but feels good to get caught up.

Ok, now that I’ve converted to jQuery v1.9, I can try out some of the new things.

The post Updating to jQuery 1.9 appeared first on JackKozik.com.