We make fairly extensive use of the AJAX Control Toolkit at work. When I first started at my current job, I wasn’t quite sure about it. In practice, most of the stuff we used seemed a little buggy and kind of kludgey. As I learned more about it, though, I started liking it. When used correctly, it’s quite useful, and holds up well, in terms of cross-browser compatibility and stuff like that.
However, once in a while, I stumble across an annoying bug. The most recent one cropped up after upgrading to a newer version of the ACT on a client site. I’m always a bit leery about upgrading the ACT, since it does often expose bugs that weren’t present in the prior version, and that don’t surface in casual testing.
In this case, we encountered a bug that occurs when you have a ValidationSummary control and a ModalPopupExtender on the same page.
If you Google the problem, you will find multiple mentions of it on StackOverflow and on the ACT bug tracker on CodePlex. The solution, basically, is to inject a script with just a semicolon in it, right after the ValidationSummary. (See here for a simple explanation.)
There are indications that the bug has been fixed, but then other indications that it re-surfaced again later. I can tell you that I was using the latest ASP.NET 3.5 version of the ACT at the time, and it’s definitely still a problem.
I don’t necessarily mind having to use these kinds of workarounds. These days, it’s fairly easy to Google an error message, and find multiple links to your problem on StackOverflow and in CodePlex bug reports, and in various other places. (I’m old enough to remember the days when we didn’t have Google or StackOverflow, so I don’t take these things for granted!) But, I would really like to encourage anyone reading this to please do one little thing for me: If you’re implementing a non-obvious workaround like this in your code, please document it with an explanation and/or a link back to the bug report or StackOverflow page. There’s nothing quite like having to do maintenance programming on a system created by someone else, finding something like this workaround on the page, undocumented, and trying to figure out what the purpose of it was.
I think that this is a problem that plagues many ASP.NET and PHP systems, especially ones that were developed with fairly loose coding standards, no peer review, and that have been around for a few years. There are often oddball workarounds in the JavaScript, CSS, and server-side code that aren’t documented and that are often fragile if tampered with. Every time I have to do maintenance programming on a system like this, I try to leave it looking at least a little bit better than it was when I started. If I can remove some unnecessary workarounds, change some non-obvious variable names to useful ones, and add some comments to explain what’s going on, I try to do that.
Speaking of the ACT, I see that a new version was released this month. Stephen Walther has been doing a lot of work on the ACT lately. This most recent release includes major revisions to (or perhaps a complete rewrite or) the file upload control. Trying to get file upload functionality working nicely on a page that’s doing a lot of tricky async stuff is pretty difficult. I used the older ACT file upload control on a page recently, and it works OK, but it required a few… workarounds. (All of which I tried to document, of course.) I don’t think that this new one will require fewer workarounds, since the basic limitations inherent in doing a file upload from a browser will still exist, but at least it will allow for some nice feedback through HTML5 upload progress events, as mentioned in the blog post.