If you are using the AJAX Control Toolkit you’ve probably noticed the ToolkitScriptManager server control.

One of the great features of the ToolkitScriptManager that comes with the AJAX Control Toolkit is its ability to combine all client side scripts that needs to be loaded in the browser into one request, thus saving the browser’s need to issue multiple requests to the server and speeding up the process of loading the page.

The URL of that combined request contains a hash code of each script that should be combined, so if you have different combinations of client side scripts due to different combinations of controls you are using from the AJAX Control Toolkit you will have a unique URL for each such request.

“So what’s in it for me?”, you ask.

It’s simple. Since these scripts are only changed when you change the AJAX Control Toolkit version (and that only happens once in a while) and these scripts can be quite large (even when Gziped), they are perfect candidates for being delivered from a Content Delivery Network (CDN).

In short, CDN can make your site faster by delivering static content (i.e. images,scripts,static html files, etc) from a location closer to the user making the request. It does that by performing the request on behalf of the user requesting that resource, caching it for a certain period of time and distributing it to server that are geographically closer to the user.

In most CDN systems you need to change the hostname of the resource you wish to be fetched from a CDN to something that was preconfigured to work with your site. The problem with the AJAX Control Toolkit is that it is the one that renders the link to the combined javascripts and you have no control over it.

Luckily the designers of the ToolkitScriptManager class thought about a hook that allows you to change the handler URL of the combined scripts.

If you’ll set the “CombineScriptsHandlerUrl” property with a URL that refers to a CDN you’ll make these scripts get downloaded through the CDN, thus making your site load faster.

For example, instead of having the combined scripts URL look like this:

This will actually make a request to the CDN instead of going directly to your site since “mycdnsubdomain.mysite.com” is a domain mapped to the CDN (of course not all CDN networks work exactly like that, but most of them work in this manner where you map a certain subdomain or another domain to the CDN).

It’s a rather quick and easy way to boost your site’s load speed with very little effort. Keep that in mind when you need to optimize the client load side of things.

Perhaps its just another case of RTFM but I might have a point here. Really.

I was using AJAX.NET and wanted to attach some silly handler to the “onmousedown” event of a link (“<a href”). I used the nice little $addHandler method in the following syntax:

$addHandler(myElement, “onmousedown”, myHandler);

And to my surprise it didn’t hook up anything.

I did what any developer would do, plunged back to the documentation and after a bit of a careful reading I saw the following line:

“The eventName parameter should not include the “on” prefix. For example, specify “click” instead of “onclick”.”

Now why should I care if I’m writing “onclick” or “click”. The convention used in browsers is “onclick”, after all that’s what you put on an element if you want to add an “onclick” handler in HTML.

Why would anyone want to break this convention. And even if you do decide to break it, adding a simple “if” or checking for the characters “on” at the start of the string and removing them would be nice.

Anyhow, I quickly changed the code to:

$addHandler(myElement, “mousedown”, myHandler);

and everything started to work wonderfully.

At least I’ve learned something new, that the eventName passed to the $addHandler function should not contain the “on” prefix. I also re-learned again that I should always RTFM, even the fine prints in the “Remarks” section.

When working with a complex environment such as the ones being created by most (if not all) AJAX applications nowadays, one needs a set of tools in his/her arsenal to overcome any obstacle.

FireBug, a web development and debugging extension for Firefox is one such tool that you must keep close.

As it site says:

Firebug integrates with Firefox to put a wealth of development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page.

If you are not already using it go quickly, download and start working with it.

There are two major benefits of using FireBug when developing ASP.NET and AJAX.NET application:

HTML Inspection – FireBug allows you during runtime and on any site, to inspect how the HTML looks. This includes direct references to the various stylesheets being used an element (including the casecading parts and from which .css file they came from). It also includes the ability to visualize the unvisible styling elements of padding and visualize so that you’ll visually see where the styling problem is as well as change the various style settings on the fly and immediately see the results.

JavaScript Debugger – The JavaScript debugger and expression evaluator in FireBug are a lot easier to use and are a lot more powerful than the ones supplied by Internet Explorer combined with Visual Studio (or what is actually Active Scripting Debugging from the happy old COM days 🙂 ). Visual Studio is a very heavy debugger and sometimes lacks the ability to debug even sites and JavaScript that you just want to know how they work, without having the actual code of the site.

In the early days of AJAX.NET (or should I say in the “Atlas” days), FireBug was my main weapon of understanding the AJAX.NET framework and stepping line by line to understand how to use and work with AJAX.NET.

It’s an invaluable tool in your arsenal and with the usage of AJAX.NET increasing on a daily basis you just have to have it.