This article describes an abstract Web Part class developed for the SharePoint 2007 (WSS 3.0 or MOSS 2007) platform. The Web Part contains the logic to address some known conflicts between SharePoint and ASP.NET AJAX, and is designed as a base class for all AJAX enabled SharePoint Web Parts.
With SharePoint (WSS 3.0 or MOSS 2007) SP1, AJAX is officially supported. However, there are still lots of manual configuration required to be performed for AJAX to work in the SharePoint environment. Basically, you can create an ASP.NET web application targeting .NET framework 3.5 and merge the AJAX related entries into the web.config of your SharePoint application. However, this is not enough. In the MSDN article titled Walkthrough: Creating a Basic ASP.NET AJAX-enabled Web Part, a technique is introduced to fix the conflict between SharePoint and the ASP.NET AJAX
UpdatePanel. This article provides a good starting point for developing AJAX enabled SharePoint Web Parts. However, the technique described in the article has its limitations as well. I will go over these limitations below and explain how they can be addressed.
Using the code
ASP.NET AJAX requires one instance and only one instance of the
ScriptManager on any page. There are several ways to include the
ScriptManager in a SharePoint Web Part page. One thing you can do is modify the Master page. Another common technique is to detect if an instance of the
ScriptManager already exists, and create one on demand if it does not. I like the latter approach as it is more flexible than modifying the Master page, which affects all pages regardless if AJAX is used in the page. After all, there are third party AJAX libraries that are not currently compatible with ASP.NET AJAX, and you may not have full control on all the contents that appears on a portal.
After reviewing the life cycles of an ASP.NET page one more time, I decided to place the logic that creates an instance of the
ScriptManager inside the
OnInit event, and that seems to work pretty well.
Another issue comes with the "EnsurePanelFix" logic, as it too should not be registered more than once. By creating a common base class for AJAX enabled Web Parts, and registering the script using the type of the base Web Part, the problem can be solved. This is especially good as not only the base Web Part promotes code reuse, it also fixes problems!
The full code for the Web Part is included below:
public abstract class AjaxBaseWebPart :
protected override void OnInit(EventArgs e)
ScriptManager scriptManager = ScriptManager.GetCurrent(this.Page);
if (scriptManager == null)
scriptManager = new ScriptManager();
scriptManager.ID = "ScriptManager1";
scriptManager.EnablePartialRendering = true;
protected override void CreateChildControls()
private void EnsurePanelFix()
if (this.Page.Form != null)
String fixupScript = @"
if (_spEscapedFormAction == document.forms.action)
var RestoreToOriginalFormActionCore = RestoreToOriginalFormAction;
RestoreToOriginalFormAction = function()
if (_spOriginalFormAction != null)
Points of interest
Despite the official support for AJAX in SP1 of SharePoint 2007, it still needs lots of effort to start using AJAX in the SharePoint environment. Maybe the next service patch for Visual Studio 2008 will provide the same support for SharePoint development as we get for ASP.NET 3.5 AJAX? Let's keep our fingers crossed.