Silverlight and SharePoint 2010

Jason Visser, Technical Architect

Development of Silverlight and SharePoint has always been very painful however with SharePoint 2010 Silverlight integration has been simplified greatly.

Why use Silverlight instead of other technologies:

1. It is easier to build for .NET developers as it uses a common language.
2. Less browser compatibility issues - either the Silverlight app renders or it does not.
3. More powerful animations, algorithms and a rich development API.
4. Very powerful client integration, e.g. out of browser support, offline mode, multi touch and access to the local file system.

Silverlight should not be used everywhere and samples of that would be:

1. When you need to capture or render rich text or html.
2. When there is large amounts of content that will be paginated and referenced by URL's.

There are 4 main ways to develop Silverlight applications with SharePoint 2010 (these can all be combined if required):

1. Read and Write to SharePoint using Web Service's.
2. Read and Write to SharePoint using the new client object model.
3. Read and Write to SharePoint using REST
4. Load data from SharePoint by rendering data on the page.

My current preferences would be using REST and the new client object model to read and write to SharePoint.

Silverlight and Web Service integration

SharePoint has always shipped with built-in web services. These include reading and writing to different areas of SharePoint 2007. SharePoint 2010 is no exception and it too ships with various web services.

A quick sample of the type of web services available would be getting lists, list items, sites, navigation, security and search. The exposed web services all make use of the in-built SharePoint security trimming.

If you do not find a web service that works for you, you can build your own web service and call that from your Silverlight application. When developing Silverlight applications using these web services, you will be using asynchronous execution and will be retrieving your result in xml form. These results can then be interpreted and manipulated using various different .net technologies. My favourite would be XLINQ which was the preferred method for reading and writing to SharePoint 2007.

Silverlight and the Client Object Model

New for SharePoint 2010 is the Client Object Model. The client object model for Silverlight is basically a subset of some of the objects that were previously not available to be used by the Silverlight API.

Object's available from the Silverlight client object model include:

• Site
• Web
• ContentType
• List
• Form
• View
• Field
• ListItem
• Folder
• File
• WebPart
• Navigation
• NavigationNode
• UserCustomAction
• RoleDefinition
• RoleAssignement
• WorkflowAssosiation
• WorkflowTemplate

The client object model uses asynchronous call's to read and write to the SharePoint site in batches. There are 2 assemblies that can now be found in the SharePointRoot\14\template\layouts\clientbin folder that include the object described above. The client object model uses a context similar to the SPContext object, this is called the ClientContext. An example of how to code using this model is:

ClientContext context = ClientContext.Current();
Web = context.web;
context.load(web);
context.load(web.lists);
context.ExecuteQueryasync(this.ExecuteMethod, null);

Silverlight and REST

You can read and write to SharePoint using REST which creates strongly typed object using the REST services. It allows you to code against SharePoint using OOP and ATOM-based means. This and the client object model are the preferred ways to communicate with SharePoint.

Silverlight and rendering data on the page as initialisation parameters

This is the oldest way of providing your Silverlight application with SharePoint data. Initiation Parameters can only read data from SharePoint using the Silverlight 'init params' method. Using this method you need to print out the data that you need to load into the Silverlight application. If there is a lot of data it will all need to be printed to the page / Silverlight object. This can be useful for initial Silverlight setups like theme settings and view settings, rather than loading up a default skin and waiting for the response from SharePoint to load up your initialisation parameters.