If you’ve been using some of the client side code available on Path to SharePoint, or other similar blogs, you might be interested in what’s going to happen when you migrate to SP 2010. I can’t provide a final answer, and we’ll see exactly how they behave when we have access to the final release. But for now let me share some preliminary results from my tests on the beta version.

Scripts that don’t need to work in 2010

First, I’d like to make it clear that some scripts are not supposed to migrate. SP 2010 comes with a bunch of new features, and some of them will address existing issues or limitations. For example, the Gantt chart in SP 2010 is more user friendly, and includes a dynamic scale. If you are using my script to dynamically resize the Gantt chart, simply drop it when you upgrade. This will make a smooth transition, as you’ll continue working in SP 2010 the same way you did in 2007.

Now how about the rest, those scripts that you’ll still want after the migration?

Scripts that rely on remote calls

These are scripts that use Web Services, the URL protocol, RSS, or other XML or HTML sources. The image Rotator and the cross-site list snapshot belong to this category. So do the scripts that use Marc Anderson’s SPservices library.
From my tests, I expect these scripts to directly work in 2010, or only require minor adjustments.
How to identify such scripts? They use the XMLHttpRequest object (look for example at the code of the image rotator), or, if written with jQuery, an Ajax function (for example load function in the cross-site list snapshot).

Form pages

Are you using code to tweak item creation pages (NewForm.aspx), display pages (DispForm.aspx) or edit pages (EditForm.aspx)? I haven’t found any significant difference between 2007 and 2010, so here too I would expect them to continue working.
I only have one script in this category (item ID in display and edit form), and it worked fine in my test.

Code that modifies SP home pages or Web Part pages

The majority of my scripts belong to this category. What they do is let the standard SP page load, then run to enhance it with color coding, animations, and other features. The most popular are the Easy Tabs and the HTML Calculated Column. Let’s review the main challenges and see how we can address them.

New structure and styles

SP 2010 sees significant changes to the page design. In the HTML, the layout is now based on divisions (div elements) instead of tables. This follows best design practices, but the pages seem to have gained some weight in the process.
SP 2010 also comes with new class names.

For class names, the fix is relatively easy: just replace the old names with the new ones. For HTML changes, scripts that are traversing the page structure will need to be rewritten. This is the case for the Easy Tabs, where I use div elements in the new version, instead of cells in SP 2007. My beta version of the Easy Tabs works with lists, but currently doesn’t work with calendars. I traced the issue back to a bug in the SP beta version (conflict between asynchronous updates and minimized Web Parts), and I’ll need to check this out in the final SP release.

Asynchronous updates

Another major change is the introduction of asynchronous content update. In SP 2007, refreshing content means refreshing the whole page. This is not the case in SP 2010, where some portions of the page can be added or modified after the page loads. Calendars for example are loaded asynchronously. For standard lists you can choose asynchronous load as well, and include periodic refreshes.

Most of the scripts I have written, or found on blogs, run once, either in the flow of the page or after the page has loaded. For example, “Text to HTML” will look for all the HTML strings in the page, and turn them into actual HTML. But what if later an asynchronous update pushes another HTML string on the page? Well, too late, it will just remain as is.
The easy way to address the issue is to disable asynchronous updates. By doing this you simply revert to the 2007 behavior. Note that AFAIK this option is not available for calendars, which are always loaded asynchronously.

If you keep asynchronous updates, you’ll need the client side script to run everytime the content gets refreshed. There are a few options to achieve this.

1/ Brute force
The easy way is to run the script at regular short intervals (for example every 100 ms). OK for small scripts and modern browsers (excludes IE 6 and IE 7).

2/ Duck punching
This refers to a technique where you append your own customization to an existing script. In our case we would append our custom script to the function(s) that render content on the page.
This is for example what I already do in SP 2007 with the Text to HTML script, to make it work with grouped views and the preview pane.

3/ XSLT
With SharePoint Designer, you can control the rendering of Data View Web Parts via XSLT. By including your customizations within the XSLT, you make sure they’ll be applied every time the view is refreshed.
Here too this is a technique I am already using in SP 2007 with the Content Query Web Part and Data View Web Part (see my blog posts on KPIs), as well as in my drop-down menu.

4/ Monitor content updates
If you don’t have control on the code, then your best bet is to monitor the page content and react to changes. What makes this method difficult to implement is that the methods to monitor changes are browser specific.
Just like for method 1/, the code needs to run at short intervals. But this time it is smarter, as it won’t go through the whole rendering process if no change has occured.
Monitoring can be done directly on a Web Part, or indirectly by tracking page changes that are triggered by content updates. For example, in SP 2010 you can monitor the notification area, which gets updated when new content is loaded, like calendar events. Here is a sample script:

<script type="text/javascript">
var watchnotif = document.getElementById("notificationArea").getElementsByTagName("span");
var count=watchnotif.length;
setInterval ('Update()',100);

function Update(){
if (watchnotif.length != count) {
count=watchnotif.length;
...run scripts on new content...
}
}
</script>

I’ll provide specific examples in future posts, and reusable scripts later this year, after the official SP 2010 release.