Client-side debugging is better, but IntelliSense still has a few issues to be worked out.
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."
Not Ready for Prime Time
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
var textb = window.$find("FormView1_TextBox1",
var textb = window.$find("FormView1$TextBox1",
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.
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.