Posts Tagged ‘jQuery’

Announcing: Debugging and TDDing Ajax with jQuery just gotĀ easier with ajaxMonitor

August 6, 2010

I am freakin’ excited!

I got tired of switching between tabs and firebug when trying to figure out what the hell was going on with my ajax requests.

The worst is when I tried finding anything about my requests in Internet Explorer. Forget it!

So I wrote a jQuery Plug-in. You attach it to your page and it will monitor all your Ajax requests [1].

One Click —-> Get the plug-in ajaxMonitor <—- One Click

The running unit tests for the source.

The running unit tests validating with jQuery 1.4.2 Ajax tests with the plug in. [2]

Two feature that are becoming a must have for this plug in

1> Mocking Ajax request by specifying your Ajax settings like this: { /*other settings*/ mock: true }

2> What I’m going to call single-shot.

  • Fire an AJAX request once
  • For all repeat requests will beĀ  mocked with the response data.

Presently the way I TDD a client, is I retrieve content using the normal Ajax call to get the presentation HTML.

Then I make another Ajax call in my normal code and store it into a string. At the start of each test I load this string into my: $(‘#contentContainer’).html(myPreloadedPresentationHTML);

Then remove it. So for all the unit tests I make a total of TWO Ajax calls. That’s one too many calls (latency can be up to 1~2 seconds OUCH!).

Since the monitor already controls the success callback of the original Ajax request why not replace it with my own.

First Ajax request success supplies the response data.
Hang onto it.
Any other calls to this request will get the stored response data.

I would welcome any comments.

Good or Bad!

…even requests.

Please help push against this software. I think it is a great tool and could be better with your help.

[1] Because jQuery 1.4.2 executes the complete callback twice during the request. If you want you can include my modified jQuery 1.4.2 library that fixes this use it. See here for bug tick #5383 .

[2] Two failing tests dealing with preserving the context. It is caused by XPC Cross Origin Wrapper. If anybody has a fix, post on

Thanks from the ajaxMonitor Team.


Is it jQuery’s fault it has leaky abstractions?

March 25, 2010

Yes and no.

No its not their fault it has a leaky abstraction.

An example of jQuery not being responsible is here:


This is due to several things. One is that different browsers give different result. Two, a border actually consists of four sides (top, bottom, left, and right), and lastly each border side has three properties (style, width, and color). WOW, just looking at a border really includes TWELVE pieces of information.

The only responsibility I see that the implementation .css should return undefined instead of just returning whatever the browser implementation returns. It should force you to select for a very specific border side and property (opinionated software):


Yes it is their fault it has a leaky abstraction.

An example:


That’s perfectly good semantics for adding classes to a selector. I say you’re right, but where it breaks down is if you need to add more than one class to a selector. you end up with this:


or you could do this:


Yawner, everybody understands method chaining. But isn’t one of the powerful tools of jQuery, is the iteration function .each. Shouldn’t we have something like this:

    $('#content').addClasses('outline left_position reset_left');

Let jQuery parse the string into an array of classes and apply it to selector.

And here is how you extend jQuery:

    jQuery.fn.addClasses = function(cssClasses) { 
        // function logic for adding
        // individual classes to selector
    $('#content').addClasses('outline left_position reset_left');

See: Adding Functions to jQuery

But hey they are only at revision 1.4.2

And those leaky abstractions can be overcome with some extension or changes in behavior. Overall even with the leaky abstractions jQuery is very powerful and useful. I recommend it for everybody.