This article describe 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 the 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 needs 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 part. However, the technique described in the article had its limitations as well. I will go over these limitations below and explained 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 to modify the master page. Another common technique is to detect if an instance of the ScriptManager already exist, and create one on demand if it does not exist. I like the later 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 3rd 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 part, and register 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 : System.Web.UI.WebControls.WebParts.WebPart
protected override void OnInit(EventArgs e)
// Register the ScriptManager
ScriptManager scriptManager = ScriptManager.GetCurrent(this.Page);
if (scriptManager == null)
scriptManager = new ScriptManager();
scriptManager.ID = “ScriptManager1″;
scriptManager.EnablePartialRendering = true;
protected override void CreateChildControls()
// Add fix according to http://msdn2.microsoft.com/en-us/library/bb861877.aspx
private void EnsurePanelFix()
if (this.Page.Form != null)
String fixupScript = @”
if (_spEscapedFormAction == document.forms.action)
var RestoreToOriginalFormActionCore =
RestoreToOriginalFormAction = function()
if (_spOriginalFormAction != null)
Points of Interest
Despite the official support of AJAX in SP1 of SharePoint 2007, it still take 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 the support we get for ASP.NET 3.5 AJAX? Let’s keep our fingers crossed.