AJAX & MOSS 2007

I figure I'll do this post while I'm thinking about it :)

WSS v3 & MOSS 2007 have a lot of moving parts, many of which are using this funny little coined model called AJAX. When dealing with ASP.NET AJAX there are a lot of different factors to think about in general, but when integrating it into SharePoint it's a totally different ballgame.

AJAX for ASP.NET is generally implemented in a very service centric manner unlike some implementations that use Callback methods and static server-side scripting pages. How does this fit into the SharePoint Model? Well thankfully WSS v3/MOSS 2007 comes with a slew of services that allow you to use the object model in a Service oriented manner.

In order to really reap the benefits of AJAX we have to find a way to have a nice mixture of Server-Side methods and Web Services to leverage in a flexible manner. To help us beat this theoretical problem, ASP.NET AJAX team gave us a nice Control known as the "ScriptManager". The Script Manager can be instantiated just like any other object using the common:

ScriptManager sm = new ScriptManager();

This Control gives the ability to register client-side scripts, services, and server-side web-methods to be used in a page code-behind. This little control seems like it answers all of prayers of a future with simple communication between the server and client...but we can't forget that this is Sharepoint!! In SharePoint every thing has to be hard!! There is a caveat to this control, a page is only allowed to have One instance of this Control! Only 1!! Hmmm... well considering that sharepoint is such a component based system with web parts, and custom controls...

How can we determine if a ScriptManager control is already on a page?

When building an AJAX enabled webpart / control this can be deemed a necessary requirement for it to function. Well there are a few approaches I've come up with to help with the pain of using such a cool control consistently for many solutions across multiple pages.

One option is to include the ScriptManager control in a Custom MasterPage used for your portal. This option works well when providing a full custom solution for a client. This can be included in the your MasterPage in this form:

< asp:ScriptManager ID="ScriptManager1" runat="server" >
< /asp:ScriptManager >

This solution works but then your webpart would have to find the ScriptManager on the page or know the ScriptManager ID to register scripts and services.

This little Method could help in finding a ScriptManager on the page or creating one if it doesn't already exist:

private ScriptManager findSM()
{
Page currentPg = this.Page;
foreach(Control cntrl in currentPG.Controls)
{
if(cntrl is ScriptManager)
return ((ScriptManager)cntrl);

}
return new ScriptManager();
}

With this method, you now don't have to even put the ScriptManager on the MasterPage but in-fact could make your webpart smart enough to know if a ScriptManager exists and if not creates one for you.

Hopefully this helps,

~:)