When we completed our SharePoint 2010 development book earlier this year, I needed a break from the same old stuff. I started looking for something new and different to sink my teeth into. Last year my writing and research focused almost exclusively on server-side development techniques for SharePoint 2010. It occurred to me that a great way to refocus my passion and my research was diving into the client-side aspects of SharePoint 2010. I started by learning the ins and outs of how SharePoint 2010 integrates master pages and CSS rules. Before too long I had also become addicted to writing JavaScript code for SharePoint 2010 and starting to integrate the jQuery library. It's been a great outlet because there is so much to learn.
When you are writing JavaScript behind a page in a SharePoint 2010 site and you want to leverage the jQuery library, you must add the appropriate script links to download one or more jQuery libraries. In some scenarios it makes sense to link to a copy of the source code for the core jQuery library that has been published on a content delivery network (CDN) such as the ones sponsored by Microsoft and Google. For example, you can link to the core jQuery library source file on the Microsoft CDN by placing the following script tag into the head section of a master page or into a placeholder control with a ContentPlaceHoldserID attribute of PlaceHolderAdditonalPageHead.
<script
language="javascript"
src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.min.js"
type="text/javascript" >
</script>
Likewise, you can link to the core jQuery library source file on the Google CDN with a script tag that looks like this.
<script
language="javascript"
src="https://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js"
type="text/javascript" >
</script>
While linking to a jQuery source file published on a CDN is often the best technique for an Internet-facing site, there are some scenarios where it might not be appropriate or it just doesn't work at all. For example, imagine you need the jQuery source code to be accessible from a virtual machine that doesn't have access to the Internet. Possibly in another scenario you are working with a beta version of one of the jQuery libraries or a jQuery plug-in that is not available on a public CDN. You could also find yourself working in a network environment with security restrictions and/or client-side caching restrictions that make it impractical or impossible to link to source code on a public CDN. In times like this, you must find a way to deploy the required jQuery library source code into the target SharePoint environment using a SharePoint solution created with Visual Studio 2010.
While you could create a SharePoint solution to deploy jQuery source files somewhere in the SharePointRoot folder such as the LAYOUTS directory, that would prevent the possibility of deploying your SharePoint solution as a sandboxed solution. This, in turn, would prevent you from deploying your SharePoint solution in a hosted environment such as Office 365. A modern, more flexible approach involves deploying jQuery source files and their dependencies using a Module and a Feature scoped at site collection level. Here are the basic steps to get started in Visual Studio 2010.
- Create a new project named MyFirstjQuertyProject using the project template named Empty SharePoint Project.
- Create a new feature named MainSite and set the feature scope to a value of Site so that the feature activates at site collection.
- Create a new Module named jQuerySource. This Module should be automatically associated with the MainSite feature.
- Add the required jQuery source files the new Module.
- Manually edit the Module's elements.xml file to modify the Url attribute of each File element to provision each jQuery source file within a folder named js. After you finish this step, your elements.xml file should look like this.
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Module Name="jQuerySource">
<File Path="jQuerySource\js\jquery-1.5.1.min.js"
Url="js/jquery-1.5.1.min.js" />
<File Path="jQuerySource\js\jquery-ui-1.8.13.custom.min.js"
Url="js/jquery-ui-1.8.13.custom.min.js" />
</Module>
</Elements>
An important point is that when deploying this SharePoint solution as a farm solution, all the jQuery source files will be ghosted which means they will load from the file system of the front-end Web Server. Therefore, this technique using a Module provides the same level of performance as deploying files into the LAYOUTS directory. However, this technique provides the flexibility of deployment as a sandboxed solution while deployment to the LAYOUTS directory does not.
When you deploy this SharePoint solution and activate the MainSite feature in a specific site collection, it will provision each jQuery source file inside the root folder of the top-level site in a child folder named js. That means you can now link to these jQuery source files using the SharePoint:ScriptLink control.
<SharePoint:ScriptLink
runat="server"
Defer="false"
Name="~sitecollection/js/jquery-1.5.1.min.js"/>
<SharePoint:ScriptLink
runat="server"
Defer="false"
Name="~sitecollection/js/jquery-ui-1.8.13.custom.min.js"/>
As you can see, the SharePoint:ScriptLink control provides a Name attribute for you to provide the path to the target JavaScript file. The Name attribute of the SharePoint:ScriptLink control directly supports the dynamic ~sitecollection token which makes it easy to create a link for pages at any offset path from the root of the site collection. You should also observe that the Defer attribute has been assigned a value of false so that the target jQuery source file is downloaded synchronously which means it can be used before the page content is shown to the user.
I created a downloadable Visual Studio 2010 sample project named My First jQuery Project and posted it in our Critical Path Training Members section. This sample SharePoint solution provisions the core jQuery library using the technique described here. It also provisions the jQuery UI library and the files for a custom jQuery theme.

The My First jQuery Project project also provisions a single demonstration page named jQueryDemo1.aspx which uses the jQuery UI library to create an According widget. This means the page is also required to link to a CSS file containing a jQuery UI theme using the CssRegistration control. Note that the name attribute of the CssRegistration control does not directly support the SharePoint's dynamic tokens so you must configure the name attribute value with an $SPUrl expression which contains the dynamic ~SiteCollection token.
<SharePoint:CssRegistration
name="<% $SPUrl:~SiteCollection/css/TedTheDramaQueen/jquery-ui-1.8.13.custom.css%>"
After="corev4.css"
runat="server" />
<SharePoint:ScriptLink
runat="server"
Defer="false"
Name="~sitecollection/js/jquery-1.5.1.min.js"/>
<SharePoint:ScriptLink
runat="server"
Defer="false"
Name="~sitecollection/js/jquery-ui-1.8.13.custom.min.js"/>
That's all the tough stuff. The body of the page named jQueryDemo1.aspx contains some HTML that is preformatted to work with the Accordion widget. The JavaScript code inside jQueryDemo1.js could not be any simpler.
$(function () {
$("#rockstars").accordion({ header: "h3" });
});
While I know it is quite possible that you have previously seen a demo of the jQuery UI Accordion widget. But have you ever seen a demo based on dead rock stars? Probably not. I am hoping this demo will prove to be a SharePoint industry breakthrough in code samples.

Here is a link to a live version of the same jQuery demo running on my blog site.