Using ASP.NET AJAX extensions in SharePoint WebParts

As I mentioned in my previous post I a while ago I started working on a project with AJAX enabled WebParts. I already have been playing with AJAX and also working with SharePoint and WebParts in my previous projects at G360 and in the .Net community. Nevertheless I did not get a chance to work with both technologies in one project, so there you go, all my wishes came true.

With the release of ASP.NET AJAX and the expected support in SharePoint SP1 it makes good sense to continue using this technology instead of other alternatives such as AJAX.NET. One of the biggest advantages is that ASP.NET developers have the choice to use UpdatePanel and the control toolkit to upgrade existing applications or develop new one without a major learning curve requirements. The UpdatePanel control encapsulates a lot of functionality and allows developers to continue to use the ASP.NET controls and programming style, but overrides the post-back events with an asynchronous call and partial update of the area covered by the UpdatePanel. Developers also have the option to go into more sophisticated AJAX development techniques using directly the client and server side AJAX libraries. With coming support for JavaScript Intellisense and debugging in Visual Studio 2008, this option will be increasingly more attractive, but in Visual Studio 2005 these luxuries are not available.

When it comes to using ASP.NET AJAX in SharePoint nothing is written in stone, but one big chunk of the mystery is solved in this post from Mike Ammerlaan - http://sharepoint.microsoft.com/blogs/mike/Lists/Posts/Post.aspx?ID=3. In his post Mike describes the steps, but there is still some work to make this function properly in a solution that can be deployed to a customer. One of the issues is how to make the web.config changes using SharePoint Feature. The solution comes from the SharePoint 2007 Features project on CodePlex, which contains a feature that does exactly that. Another issue is that to add the script manager we don't really want to edit to the master pages. Even though some don't recommend this technique, I found that adding the ScriptManager dynamically worked well for my project and greatly simplified the deployment. This is the code I used:

protected override void OnInit(EventArgs e)
{
base.OnInit(e);

// Let's find if the ScriptManager exists and add it if not
scriptManager = ScriptManager.GetCurrent(Page);
if (scriptManager == null)
{
scriptManager = new ScriptManager();
if (Page.Form != null)
{
// Insert script manager after the web part manager
for (int controlIndex = 0; controlIndex < Page.Form.Controls.Count; controlIndex++)
{
if (Page.Form.Controls[controlIndex].GetType() == WebPartManager.GetType())
{
Page.Form.Controls.AddAt(controlIndex + 1, scriptManager);
}
}
}
}
}

Using ASP.NET AJAX Control Toolkit was also very straightforward. Most of the controls worked properly in SharePoint. I did not have the chance to test all of them, but it looks like controls that iterate many objects on the page and make style modifications to many controls work somewhat slower, if at all, in the default SharePoint page. The validation extender, for example, sometimes does not position well the call out next to the field, or the modal pop-up mocks up the whole page and causes high CPU utilization. Nevertheless there are plenty controls that work well. One of the controls I use frequently is the tabbed control, which is very handy for configuration pages.

One thing I found cumbersome is to use UpdatePanel and some of the other AJAX enabled template controls directly from server side code. I know a lot of web control and WebPart developers have long forgotten the design-time environment of the web forms, but would it be nice to be able to use a visual tool to design WebParts and to be able to easily test them? I hope I'll find some time to write about the solution I worked out for my projects. Until then ...

Dovizhdane!