We just launched the first version of the site where we depend completely on ASP.NET AJAX to do all our script management. Here’s what we did in this initial phase:
- Added ScriptManager to our Master Page and ScriptManagerProxy to any content pages that required it
- Changed all static <script> tags to be ScriptReferences
- Changed all use of ASP.NET 2.0’s ClientScriptManager to use ScriptManager instead (i.e. RegisterClientScriptInclude, RegisterStartupScript, etc.)
- Implemented IScriptControl on our custom controls so now, for the ones that used to have to register their scripts manually through RegisterClientScriptInclude, we just return them through GetScriptReferences
- Upgraded our ComponentArt to the version they released that is ASP.NET AJAX compatible
- Modified all client scripts to use:
- pageLoad/Sys.PageRequestManager.add_pageLoaded – using these in place of hooking into window’s load ourselves
- $get – using in place of direct calls to document.getElementById.
- $addHandler/$removeHandler – in place of proprietary DOM event support detection/registration code we’ve had for years.
- XMLDOM – this class is not technically supported by ASP.NET AJAX, but it’s a wrapper around the instantiation of the MSXML DOMDocument ActiveX component for IE or the native DOMParser JavaScript object for other browsers. Up until this we had our own mini-XML parser written in JavaScript using regular expressions.
- Threw some UpdatePanels around the content section wherever we used a ComponentArt TabStrip along with an UpdateProgress control to indicate when the content of the tab is loading.
- Overhauled our print file previewer, which shows images of files that are uploaded to use Ajax Control Toolkit Slider and Animation features to make the experience smoother.
- Implemented an auto-save-draft feature for our document building process which calls a web-service 30 seconds after any change in the editor. This uses the built in support for calling ASMX services.
All in all the experience was very smooth. There is one snag to using UpdatePanels that bit us though. If you have controls that normally include their own <link>s to stylesheets by adding them to the <head> via the HtmlHead control, if those controls are dynamically loaded into an UpdatePanel during an async-postback those stylesheets will not arrive at the client and your controls will not render appropriately. This is because ASP.NET AJAX doesn’t handle the <head> content changes when returning an async-postback response. I can find no way to overcome this at this point using ASP.NET AJAX.
I therefore began writing my own StyleSheetManager class which is akin to ScriptManager. The idea would be that in the case of an async-postback, the StyleSheetManager server-side class would emit a startup-script (via ScriptManager::RegisterStartupScript) that is an Array of URLs that need to be loaded. That would be passed to a client-side function that would essentially make calls to dynamically add <link> elements to the <head> with the various style sheet URLs. I’m hoping this will work cross-browser, but I have yet to find the time to finish and fully the control. When I do, I’ll be sure to post my findings and maybe even the code.
In all, I’m extremely pleased with ASP.NET AJAX. In the next phase of ASP.NET AJAX migration for this project we have the following planned:
- Convert all client-side components/controls to the ASP.NET AJAX class/component/control model (i.e. properties, standard prototype approach, member variable naming with underscore prefix, namespaces, type registration, etc.)
- Replace proprietary eventing model with ASP.NET AJAX event model
- Replace proprietary client side resourcing model with ASP.NET AJAX resourcing support
- Replace all custom parsing/formatting functions for dates/numbers/etc. with built in ASP.NET AJAX globalization
- Replace proprietary debug calls with Sys.Debug
- Replace proprietary focusing logic with ScriptManager.SetFocus
We’ve also begun a new, separate project which is being built from the ground up to be 100% ASP.NET AJAX based. When that’s done, it’s going to be a a great showcase for what’s possible with this technology!