Saturday, February 20, 2010

Working with SharePoint 2010 Client Object Model

Hi all, 

There an event conducted by SharePoint user group @ Singapore. This session was to learn the new client object model in the upcoming SharePoint Server 2010. 

The session will cover the following key areas:
• Client Object Application Architecture Overview
• Client Object Model versus Server Object Model.
• Developing Client side applications using .NET Managed Code and ECMA Script.
• Deployment considerations with Client Side Object Model

 Razi Bin Rais (SharePoint Server MVP) conducted the session and facilitated by Steve Sofian. 


Why Client Object model??
Microsoft was getting lot of requests from customers, partners for making more web-services so that we can get data out of SharePoint. Therefore, request of more web-services or write your own custom web-services. 

Microsoft took a different approach and developed a "Client Object Model" and exposed in three different flavors in consistent developer experience across platforms namely:
1) .Net.
2) ECMAScript
3) SilverLight.

For e.g. A javascript can run inside the page and is loaded with SharePoint site.  Now, what will happen is that we can circumvent the heavy SOAP-based web services like list service. The best part of client object is strikingly similar to server object model.     

Advantages of client object model: 

>>Site Collections and Sites
>>Lists, List Items, Views, and List Schemas
>>Files and Folders
>>Web, List, and List Item Property Bags
>>Web Parts
>>Content Types
>>Site Templates and Site Collection Operations

and limitation of client object model: 

 Equivalent Objects: 

The server objects are very similar to client object model. Programming against server objects in the server context is similar to the new client object model and uses "ClientContext" for all the operations.

.NET Managed

Following are the resources and locations where client object are stroed: 

Server – Microsoft.SharePoint – [..]\14\ISAPI

1) Client object model:
1) .NET – Microsoft.SharePoint.Client – [..]\14\ISAPI
2) Silverlight – Microsoft.SharePoint.Client.Silverlight – [..]\14\LAYOUTS\ClientBin
3) ECMAScript – SP.js - [..]\LAYOUTS

As we can notice is that we have 2 different flavors: 

1) .NET Code (.NET managed code and Silverlight)
2) ECMAscript (javascript)

The reason we have different flavors is that read-write properties are different from ECMAscript and .NET code.The syntax are slightly different but the concepts are similar.     

Consider, SPContext obejct is on server side. We can get the same thing on "ClientContext" which is a frame of reference for SharePoint for client model.  Here we pass in the URL for the site you are trying the hit. 

Javascript is different as we CAN NOT pass the URL because if we this, it will cross-site scripting.

Using the Client Object Model: 


Following are notes with respect to client model:

>>Manage client OM = .NET / Silverlight
>>All communication goes through the client.svc WCF service
>>Microsoft implemented the client OM by decorating the core SharePoint OM with attributes if it was “client aware”
public class SPWeb {}
>>Then a code gen tool generates the client OM assemblies and JavaScript
>>This ensures that there’s fidelity between all the client OM’s and the server equivalent. 

For e.g. 

// get a context

using (ClientContext clientContext = new ClientContext(""))

    //Get the Site Collection
    Site site =

    //Get the top level site
   Web web = clientContext.Web;

   // get only the list titles

   clientContext.Load(clientContext.Web, x => x.Lists.Include(l => l.Title).Where(l => l.Title != null));

   foreach(List list in web.Lists)



//Get the Site Collection
When we get client context, we client model is smart enough and will not get everything from the site collection. At the last line, we get a light weight site collection.  

//Get the top level site
Do the same thing for the top level site.

//Get the only list "Title"
clientContext.Load(clientContext.Web, x => x.Lists.Include(l => l.Title).Where(l => l.Title != null));

Linq "Lambda" syntax.  This is a less-friendly, but at least consistent and more powerful, way to request data using Linq.  Although a lot of scenarios may start with the "Pretty Query" syntax, in many cases Lambda syntax must be used for more advanced scenarios.

Now, when we execute clientContext.Load, we use lambda expression to fetch only titles where title is not null in the top level sites Therefore, we will get the light weight object back.  

2) ECMAScript Client OM

SharePoint 2010 sports ECMAscript (or Javascript) with the client object model. It will give the ability to work on the client after the page is loaded directly with the SharePoint keeping us without any kind of post-back stuff. Although, it does not allow site to another because it will lead to cross-site script and its a big no no in web. 

  Microsoft has developed a javascript library called as "sp.js". ECMAScript Client OM is easily added to a SharePoint ASPX page - reference: 

>> _layouts/sp.js
>> Add this using <SharePoint:ScriptLink>

All compressed and crunched libraries crunched for performances namely  SP.js, SP.Core.js, and SP.Runtime.js. The reason also for users so that they dont have to wait for page to load. 

Use un-crunched *.debug.js by adding <SharePoint:ScriptLink … ScriptMode=“Debug” /> and its only for testing purposes. 

3) SilverLight Client OM 

 In SharePoint 2010, its more easier and powerful to interact with SilverLight applications. There is automatic plumbing in place on the web front end.  There are several benefits: 

>> SilverLight development enabled by Client Object Model.
>> We can use SilverLight in a separate ASPX page or in Web Part.
>> SharePoint 2010 comes with SilverLight web part.


No comments:

How to: Use cascading drop-down lists in PowerApps

Hi all, Using cascading dropdown, users can easily fill the forms by selecting drop-down values dependent on values from another dro...