Using Ajax.NET Pro in a SharePoint Web Part

• Download Ajax.NET Pro 6.7.20.1 - 178 Kb
• Download example web part CAB - 4.94 Kb
• Download example web part source - 9.84 Kb

Introduction

Just like everyone else, I'd heard the buzz about AJAX but had never really tried it out; both from a user perspective, and programmatically! I do a lot of programming for my work, and one of the environments I'm spending a lot of time developing in is SharePoint, and in particular, web parts. Having created quite a few web parts, one of the things I became quite aware of is that performance can be an issue. When there are lots of web parts on a Team site, any user interaction with a web part will cause all of them to have to be refreshed, which can be slow if the web parts are complex (like ours are). So....the answer to me seemed to be AJAX! OK, I was using it as an excuse to try out AJAX, but in the end, it was the right decision to solve my problems. Sometimes, it's better to be lucky than good :)

Being a true programmer at heart (i.e. lazy:)), I decided there must be an easy way to do this! I looked through a whole bunch of AJAX libraries and frameworks out there, but in the end, came across Ajax.NET Professional, and really liked it. It seemed to be robust, complete, lightweight, well used, and well supported. So, next step, how to get it working with my SharePoint Web Part? Well, that was where it got interesting. Although there is great documentation with Ajax.NET, there was nothing specific to SharePoint. Eventually, I found some hints in the Google Ajax.NET forum which then led to me finding a blog entry by Maxim Tarassenko that was enough to get me to a working solution.

This article (I hope!) will serve as a single reference point in what to do to enable Ajax.NET Pro within SharePoint so that web parts can be created that can use AJAX. What I will not be doing is trying to explain how to create web parts or go into detailed examples of Ajax.NET Pro usage! The aim is to make every step clear and easy, even for a SharePoint novice, so if any steps are not clear, let me know and I'll try and explain them better!

Installing Ajax.NET Pro

The example project Web Part was created using version 6.7.20.1. Once this, or the current latest release, has been downloaded and the contents extracted to a directory (you'll need to have it handy for referencing when creating code, so put it somewhere permanent), the following steps will configure SharePoint:

1. Install AjaxPro.dll into the GAC. I prefer to use the GAC because it makes security easier, and there is only ever one place the DLL is installed to!
2. Add the AJAX HttpHandler to the web.config file for each SharePoint Portal site that you want to AJAX enable.
3. Add the /ajaxpro path to the list of excluded paths for each portal site.

Once these steps are done, SharePoint will be able to have web parts that use Ajax.NET pro. There are a couple of tricks that must be used within the server and JavaScript code though!

Installing the Ajax.Net Pro DLL in the GAC

I prefer to use the GAC because it makes security easier, and there is only ever one place the DLL is installed to! There are several ways to do this, but the simplest, to me, is to drag-and-drop the AjaxPro.dll into the c:\windows\Assemblies directory.

Adding the HttpHandler

This step must be done manually by editing the appropriate web.config file for each SharePoint Portal site that Ajax.NET is to be enabled for. In the web.config file, locate the <httpHandlers> section - it will probably have the two default entries as follows:

<httpHandlers>
  <add verb="*" path="/_vti_bin/*.aspx" 
       type="System.Web.UI.PageHandlerFactory, System.Web, 
             Version=1.0.5000.0, Culture=neutral, 
             PublicKeyToken=b03f5f7f11d50a3a" />
  <add verb="*" path="*.aspx" 
       type="Microsoft.SharePoint.ApplicationRuntime.SharePointHandlerFactory, 
             Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, 
             PublicKeyToken=71e9bce111e9429c" />
</httpHandlers>

Add the following entry to this section:

<add verb="*" path="ajaxpro/*.ashx" 
   type="AjaxPro.AjaxHandlerFactory, AjaxPro, Version=6.7.20.1, 
         Culture=neutral, PublicKeyToken=4735ae9824c7d3ec" />

Excluding the /ajaxpro path

This can be done in one of two ways; either through the (graphical) SharePoint Central Administrator, or by using the (non-graphical) stsadm command-line tool.

Using SharePoint Central Administrator

1. Click Start, point to All Programs, point to Administrative Tools, and then click SharePoint Central Administration.
2. On the Central Administration page, under Portal Site and Virtual Server Configuration, click Configure virtual server settings from the Virtual Server List page.
3. On the Virtual Server List page, select the virtual server you want to configure.
4. On the Virtual Server Settings page, under Virtual Server Management, click Define managed paths.
5. In the Add a New Path section, in the Path box, type /ajaxpro.
6. Select Excluded path for the Type.
7. Click OK.

Using stsadm

1. Open a Windows command prompt.
2. cd C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN (on a side note, I add this to my PATH environment because I use stsadm all the time).
3. stsadm -o addpath -url http://your_server_portal_name/ajaxpro -type exclusion.

The Web Part Code

The first thing you have to do with Ajax.NET Pro is to register your types (class or classes). This should be done once, so a good place is on page load. The command to register the type is:

AjaxPro.Utility.RegisterTypeForAjax(typeof(UserInfo), this.Page);

Replace the UserInfo with the name of your type.

The other thing that must be done is to register the JavaScript that will be used to implement the AJAX functionality on the clients! I do this in pre-render.

The JavaScript Code

The last "problem" was how to initiate a client side call through Ajax.NET Pro when the web part is first loaded without the user having to do anything! This bit is what took the longest for me to get working:) At first, I thought I could add something to the web parts page load code (same place I put the type registration code), but that does not work. What I really needed to do was add it to the actual page OnLoad event. The trick was to have my JavaScript do it for me! Here is the code, which sits at the top of the JavaScript I registered within the web part:

try{
  window.attachEvent("onload", 
         new Function("AjaxUserInfoInit();"));
}
catch(ex){
    //Do Nothing
}

This will call the JavaScript function AjaxUserInfoInit when the page (web part) is first loaded. In here, I then execute a call, or calls, back to the web part DLL to execute my initial code.

A Word About the Example

The example is very silly and trivial in that all it does is to display a message when the web part is first rendered, letting the user know something is being done (just like Microsoft Outlook Web Access):

This "something" is a couple of Ajax.NET calls that will return data that is displayed in the web part:

One of the big AJAX debates is what should the AJAX function do; return data so that the JavaScript can dynamically create the HTML from the data and then update the page, or simply return HTML to be displayed? My example uses both methods to display the same data. Again, trivial, but I was testing both approaches to make sure I could do them! As to which approach I will use in the future? Not sure! I guess what I will use will depend on how much data has to be transferred to the client for the JavaScript to be able to generate the HTML. If that information is greater in size than the resulting HTML, then I'll format the HTML in the Server and just transfer the results.

Conclusion

Hopefully, this will get the creative juices flowing, and you'll be able to change your web parts into AJAX extravaganza's:) Well, that's my intention for my customers! I'd like to think that by using AJAX, I will enhance the user's experience by improving the feel and speed of SharePoint - less page refreshes is a good thing.

History

• 08-02-2006:
  • Original article.