ajax

Packet level debugging for Ajax traffic

I encountered a session cookie issue while working with an ajax interaction. To debug this, Rinaldo suggested me to try a tool called balance. It is a proxy with the capability to output protocol level human readable debugging information. It is a lot easier to work with than other network monitor tools such as Wireshark, which I had to read the raw pack data. With balance, since the header information is human readable, I can easily filter out unwanted information by specify a keyword. In the example below, it will print all client submissions of cookies and all server responses with set cookies. The -fpd options will cause the tool to print all traffic to standard out. Rest of the parameters in this example forwards all traffic to the local host at port 8081 to the destination host “localhost” at port 8080. Thanks to Rinaldo, this tool helped me to get to the root cause that I was trying to identify.

balance -fpd 8081 localhost:8080 |grep Cookie

Applying time stamp to YUI AJAX calls for IE

In my previous post on this topic, I described the basic idea on using time stamp to work around the caching issue with IE. Here are additional notes on how to time stamp enable various YUI components using the same concept.

For autocomplete widget, you can override doBeforeSendQuery function and manually add timestamp parameter. See API document for more information.

For datatable widget, you can manually add time stamp parameter to initialRequest parameter. See documentation for more information.

If you are working with a connection object, you can configure cache:false in the callback function. This will automatically add the time stamp workaround for you. See documentation for more information.

A cool AJAX trick to solve IE caching issue

IE loves to cache AjAX calls. If your JavaScript makes repeat calls to get new data, IE would not even bother to make that call and will just give your script a cached response. IE would not even honor no-cache headers for my AJAX requests. A popular trick that I learned from a friend and this discussion thread was to use a dummy parameter that will always different for each AJAX call. For example:

var d = new Date();
var myURL = "http://myserver:myport/myapp/myaction?d="+
d.getDate() + d.getHours() + d.getMinutes() + d.getMilliseconds();

Or you can use a simple counter variable.

A RFE for Visual Web Developer 2008 Express Edition beta 2

After using Microsoft’s Visual Web Developer 2008 Express Edition beta 2 for debugging JavaScripts in IE for a while now, I really wish developers of such a fine product to check out FireBug’s console. I wish an equivalent feature is available in Visual Web Developer 2008. This will help me to examine AJAX requests and responses to troubleshoot data exchange issues with IE. Or let me know if it is already available. Thanks.

NetBeans 6 beta 1 is more JavaScript friendly than earlier releases

I’ve been using NetBeans 6 beta 1 for a while now. Today I just found out that if I am working on a static file such as a JavaScript file, all I need to do is to redeploy the project to the local server instance to see the changes. No need to rebuild or recompile. This is very cool. I don’t have to wait for the compilation of all that Java code in the same project to see changes in JavaScripts. This saves me a lot of time and I don’t have to go to a command line and do the copy myself. Again, very cool!

A simple JavaScript trick

Given a JSON array, or any JavaScript object array, how do I find out the size or the length of the array without a length or size property? This is actually a very simple to solve. Just use for ( x in y) statement and use a counter variable to increment the count while you process through the data in the array. Here is one example:

var count = 0;
for (x in array){
    array[x] = 0;
    count++;
}

If all you do with the length/size information is to traverse through the array in for (int x=0; x<arraySize;x++), then you can just use the for ( x in y) statement without the extra counter variable. If you have a simpler trick or an obvious fact to share, just leave me a comment.

More Columnav Feedback

Columnav is definitely a cool widget when you have a small data set with not too many items for each column. Once the number of items grow to a certain size, the response time suffers. Introducing extra levels of clicks can only help to a certain extend before the users get confused or annoyed with the large/complex navigation tree. As a recommendation for a future release of columnav, how about adding a Predictive Fetch feature to columnav? This will allow the users to see an initial set of items immediately. When the user scrolls down the list, approaching the end of existing chunk, the widget fetches the next chunk, which enables the user to continue navigating with little wait.

webtest and jWebUnit: first impression

I spent a little bit of time check out both webtest and jWebUnit. Here are my first impression:

webtest is declarative and XML configuration file driven. If you like configuration management more than programming, you might like this format. All you need is edit the test definition and hit the run command, no compilation necessary. If you have well formed HTML and working JavaScript, then you should not have too much trouble running this. My initial simple test case works once I commented out the non-working and irrelevant JavaScript reference in the HTML. I tried to take another mini-step forward by attempting to “configure” a click to select one of the link items in a JavaScript widget. Webtest has 3 ways to click on a link, by ID, label, or xPath. The widget’s link item doesn’t have an ID, so I can’t use that. I tried label and that didn’t work. Then I tried xPath and that didn’t work for me either. So, that second mini-step didn’t go very far for me. Any one know an open source xPath validation tool or web site?

jWebUnit is one of the many unit testing frameworks based on jUnit/HtmlUnit. The interesting aspect of this framework is that it supports both HtmlUnit and Selenium test cases. jWebUnit uses similar programmatic model as jUnit, so you can stay comfortable within your favorite IDE. I was able to create a new project in NetBeans and leverage it’s jUnit feature, by creating an unit test and rewrite that as a jWebUnit test case, while using NetBeans to drive the test execution. jWebUnit, or the underlying HtmlUnit engine appears more picky about JavaScript than Webtest, I had to start tweaking YUI libraries in an attempt to load a page, which shouldn’t be something that I supposed to be doing anyway. Perhaps YUI engineers use a different unit testing framework. The test page actually loads without a major issue in Firefox.

Both frameworks do share one thing in common, both do not use actual browser instances to drive the testing. And that explains why they don’t work as well as some of testing frameworks that built within or on the real browser instance because of behavior differences when processing JavaScript. At the same time, both may have one advantage over browser based testing framework, which is the ability for non-interactive testing through ant and is very useful for continuous integration servers such as CruiseControl. Again, I’ve only looked a few testing frameworks and let me know if you know a browser based unit testing framework that works with ant. Thanks.