Practical ASP.NET

JavaScript and AJAX in ASP.NET: Not Quite Ready for Prime Time

Client-side debugging is better, but IntelliSense still has a few issues to be worked out.

• By Peter Vogel
• 06/04/2008

Back in an article on the beta of AJAX for ASP.NET ("Build Smart Web Apps With Atlas" in the March 2006 issue of Visual Studio Magazine), I said, "There's still much to be done before Atlas is ready for prime time. Debugging is awkward, and the lack of IntelliSense support in Source view means that coding is error prone."

Those two specific problems have been addressed in Visual Studio 2008 and .NET 3.5 -- sort of. Client-side debugging is much improved in Visual Studio 2008. But IntelliSense support for JavaScript is only "sort of" better. The good news is that IntelliSense will now show you all the HTML objects on the page.

Not Ready for Prime Time
The bad news, however, is that IntelliSense won't show the ASP.NET objects on your page because, of course, the HTML tags for these controls aren't generated until runtime. It's not really a satisfactory solution: The only way in JavaScript to access an ASP.NET control is by passing the name of the control to a method that will return a reference to the ASP.NET object, which isn't a reliable solution.

There are two methods you can use for retrieving an ASP.NET control at runtime: the DOM-standard getElementById or Microsoft's $find extension. This is the code that you'd use with the getElementById method to retrieve a control with its ID attribute set to TextBox1:

var textb = window.document.getElementById("TextBox1");

Using $find is more forgiving (it will search both the ID and name attributes of a tag, for instance) but only works reliably in Internet Explorer. With the $find method, you pass the name or ID of the control you want and the container you want to search in (typically, window.form1). This example retrieves the control with TextBox1 in either its ID or name attributes:

var textb = window.$find("TextBox1", window.form1);

Once you've retrieved the object, you can set or retrieve the control's value property:

textb.value = "Hello, World";

While these methods work, they're hardly satisfactory. Since you're passing a string to these methods, there's every possibility that you'll spell the name of the control incorrectly when you write your code. This is the worst kind of bug: a problem that you won't discover until that line of code executes.

Working with Naming Containers
However, the code does work in a wide variety of scenarios: if the control you're searching for is sitting directly on the page, is in a panel, or even if it's in a View control. Unlike the server-side FindControl method (which I covered in my column "Using Findcontrol and PreviousPage with Master Pages"), this client-side code also works even if your page is based on a Master Page. However, if the control you're searching for is inside a naming container like a FormView, then the code will fail.

To find a control inside a naming container, you'll need to pass the fully qualified name or ID attribute for the control you're looking for. For a text box named TextBox1 inside a FormView named FormView1, any of these lines of code will find the control:

var textb = window.document.getElementById
   ("FormView1_TextBox1");
var textb = window.$find("FormView1_TextBox1", 
   window.form1);
var textb = window.$find("FormView1$TextBox1", 
   window.form1);

This code will fail, however, if the template in the FormView that contains TextBox1 isn't being displayed when the code executes. Some error handling to check that the control was found before setting the control's value property will handle that problem:

if (textb != null)
{
   textb.value = "Hello, World";
}

However, this code will also break if:

• The name of the containing control (the FormView) is changed.
• The containing control, with all of its child controls, is moved inside some other containing control.
• Microsoft changes the format used when generating the ID or name attributes of HTML controls inside a naming container.

And, to repeat an earlier point, you won't get a compile time error in any of these scenarios until you execute the offending line of code in the browser. And, if my experience is any guide, it will probably be an end user who discovers the problem.