It’s pretty likely that you have some JavaScript files used on your site or in your custom controls, etc. Now that you have added MS AJAX libraries to your site, you want to add those capabilities slowly to your existing JavaScript files.

So, now you want to refactor your existing JavaScript files little bit at a time – not so much as to cause headaches. Following are some suggestions.

Figure 1. Adding ASP.NET AJAX to existing projects

Add ASP.NET AJAX infrastructure

First step is to add the ASP.NET AJAX (MS AJAX) infrastructure to your site/page. This, at the most fundamental level, mean adding ScriptManager control to the page where your own custom control or JavaScript is used.

Add ScriptManager

So, the very first step would be to add ScriptManager to the page. This could come from the Master Page or you can add it to the page under consideration. For ASP.NET AJAX to be enabled, there must be one and only one instance of the ScriptManager on the given page. If your site is already ASP.NET AJAX-enabled, then you don’t need to add this again.

So, within the <form></form> tags, add the ScriptManager control:

If are not going to further manipulate ScriptManager on your page, this declaration can be as simplified as the following:

If your custom control already knows where to get the JavaScript files, adding the above will bring the client side JavaScript files from the ASP.NET AJAX library. So, you can start using the functionality from there.

Check for ScriptManager

If you are going to rely upon the ASP.NET AJAX capabilities in your custom control, you need to make sure there is a ScriptManager on the current page. There is a static method called GetCurrent() in the ScriptManager class. This method returns the current instance of the ScriptManager.

You would need to check for the existence of ScriptManager from your custom control, before proceeding too far. Perhaps, the best place could be in OnPreRender handler of your custom control.

Listing 1. Checking for the existence of ScriptManager

As shown above, you can try to get the current ScriptManager and throw an exception if it’s not there. The commented out portion shows it in an elaborate way – assigning the ScriptManager to a variable and checking whether it’s null or not. If you are going to do something more with this variable further down in that method you can use the commented out code.

Remove Browser Detection Code

It is very likely that you have some browser detection code in your old JavaScript files. There are a couple of different ways of doing this, and in most of the cases, this code can be removed.

Detecting the browser up-front

Typically, this would some piece of code that checks the userAgent string on the Navigator object. By using indexOf on the userAgent string you will look for the strings ‘Safari’, ‘Opera’, ‘Gecko’, etc. If something like navigator.userAgent.indexOf(‘Safari’) is true, then it is a Safari browser. In the old days, there used be a lot of checks on what properties document object supports (all, layers, etc.) – and based on this and the above, the browser would be established.

Typically, this code can be replaced by:

• Checking whether it’s a supported browser on the server side and if it’s not supported, just not proceed with showing the custom control.
• Doing the feature testing, as discussed in the next section.

If you need to check the browser on the client-side, see the following article:

Browser Detection from the Client-Side in ASP.NET AJAX

You can detect the browser on the server side by using the class HttpBrowserCapabilities:

Doing the feature testing

This is used at the time of using a particular feature. For example, addEventListener is used by FireFox for adding event handlers, where as attachEvent is used by IE. So, just before adding event handlers, you will see if these methods are available on that particular element – for example: if (elem.addEventListener) … add the event listener for FireFox, and so on.

Even this feature checking code can be replaced by using the functionality in ASP.NET AJAX (which does this feature checking for us). For example, the event handling mechanisms of individual browsers can be replaced by the event handling mechanism of ASP.NET AJAX (discussed in a section below).

Use the Shortcuts from ASP.NET AJAX

ASP.NET AJAX client side library provides a few global short cuts for the most commonly used JavaScript DOM methods. The most commonly used method is document.getElementById, which is used to get the HTML Id by specifying its Id.

If you are using the complete document.getElementById each time you are getting an HTML element, you can replace that long string with $get global short cut from ASP.NET AJAX (it’s very possible that you have your own shortcut for this or if you used some other client side library like Prototype, you might have used something like $ as a replacement for document.getElementById).

For example, the following line:

Can be replaced with

Following additional global shortcuts are also available: $find, $create, and the event handler short cuts ($addHandler, $removeHandler, $addHandlers, $clearHandlers) that we discuss below.

Use ASP.NET AJAX Event Handling Methods

There are four event handling shortcuts, as mentioned above. The existing event handling code can be changed to use these short cuts.

For example, the following code that works for FireFox:

Can be changed to the following:

Next Steps …

Various changes discussed above are the first steps towards migrating existing JavaScript code to use the ASP.NET AJAX libraries. From here on, a lot of additional changes can be made to the js files – adding namespaces, placing the existing code into classes, etc.

Related Articles

Browser Detection from the Client-Side in ASP.NET AJAX

How does an MS AJAX extender control get initialized on the client side?

The structure and usage of AutoCompleteExtender control

JavaScript files with RegisterClientScriptInclude and ScriptManager

Embedding JavaScript files in your custom controls