SharePoint 2007 allows using its Object model to run against server
running SharePoint. For clients (not running SharePoint in the box) the
simplest way to communicate with SharePoint server is web services.
SharePoint Client Object Model (OM) can be run on client PC (where
SharePoint is not installed) to communicate with SharePoint server. So
whereas SharePoint (Server) Object Model runs in a SharePoint server and
can manipulate SharePoint objects, Client OM can run in client PC and
communicate with SharePoint server remotely.
SharePoint 2010
introduces three new client APIs which can be used to interact with
SharePoint sites. The three APIs are targeted for three different types
of clients:
- For .net Managed applications (Eg:
console applications, window applications, web applications).
- For Silverlight applications.
- For using with JavaScript (called ECMAScript or JSOM).
- This API is only
available for applications hosted inside SharePoint (for example, web
part deployed in SharePoint site can use this JavaScript API for
accessing SharePoint from browser using JavaScript).
Lets see some
basic problems SharePoint 2017 in absence of Client Object Model.
Why Client Object Model (OM)?
SharePoint
2007 had no Client Object model available. So you may ask why this is
introduced in SharePoint 2010? We had no problem without Client OM and
millions of sites are running smoothly without having Client OM. The
main reason is that Microsoft has found lot of requests from SharePoint
users to introduce more and more web services to get data out of
SharePoint in the last couple of years. But introducing web services
will not fix the issues, as Microsoft found, because then the request
for more functionality in the web services will continue. Even if
Microsoft provides a good numbers of web services with SharePoint,
customization in web services will be required for different clients and
this will make the out of the box web services unusable. Also
introducing a large number of web services will be a waste as not all
companies will use all the web services functionalities.
In
response to add more web services from users, Microsoft has taken a
different approach called Client Object Model (OM). This SharePoint
Client OM will allow getting data out of SharePoint from PCs that are
not hosting SharePoint. Also Client OM provides complete API to interact
with SharePoint Server which is more intuitive and useful and very much
similar with SharePoint Object Model.
Similarity with SharePoint Object Model
The Client OM familiar with SharePoint
Object Model as below.
| Server (Microsoft.SharePoint) | Client Object Model |
| SPContext | ClientContext |
| SPSite | Site |
| SPWeb | Web |
| SPList | List |
| SPListItem | ListItem |
| SPField | Field |
So
the class names in Client OM are similar as like SharePoint Object
Model. However the way client OM will be used a bit different than usual
SharePoint Object Model that we will explore in the upcoming posts.
How Client OM is developed and work under the hood?
It’s
interesting how SharePoint team has developed the same set of classes
for three different sets of applications (Managed, Silverlight and
ECMAScript)
| Client Type | Assembly/File |
| Managed Client | Microsoft.SharePoint.Client |
| Silverlight | Microsoft.SharePoint.Client.Silverlight |
| ECMAScript | SP.js or SP.debug.js |
To
ensure the same class object (say ListItem) behaves similarly in three
different types of applications SharePoint team followed the steps
described below:
a) SharePoint team first set attributes to the
SharePoint classes and methods and properties that need to be exposed
in Client OM.
b) Then a code generator is run against the SharePoint object model to generate client OM automatically.
This
automated code generation has ensured maximum compatibility between
these three sets of APIs. As the following figure shows client
communicate to the server thorough Client OM which under the hood uses
Client.svc WCF service to communicate with SharePoint Server. Client.svc
service uses Server OM as per client request and return result to the
client in JSON format.
Figure: How Client Object model works with Server
With
this new Client OM, we almost don’t need to use web service to
communicate with SharePoint server.
Client Object Model for JavaScript (ECMAScript)
Lets go through Client OM for JavaScript. ECMAScript Client OM is
SharePoint 2010 client object model extension for using with JavaScript
or JScript. Few points to notice about ECMAScript Client OM:
- ECMAScript object model can only be used in SharePoint sites. So you
can’t use this object model in an asp.net site to access SharePoint
resources deployed in another url as this is cross-site scripting and
not allowed.
- You can’t use this object model in a SharePoint site to access
resources in different SharePoint sites(i.e., different urls).
- You can use JQuery with ECMAScript Client OM by adding reference to JQuery.js.
- You can use this ECMAScript Client OM in web part pages or
application pages (aspx pages) by referencing a javascript file (SP.js).
You don’t need to add reference to the file manually.
- Rather use
<SharePoint:ScriptLink Name=”sp.js” ………. />.
- Location: “Program Files\Common Files\Microsoft Shared\Web Server
Extensions\14\TEMPLATE\LAYOUTS”
- To update with JavaScript, you need to add a FormDigest tag in your
page for security purpose. I’ll explain it later in details.
Use Client OM to retrieve data:
<script type="text/javascript">
function getWebProperties() {
var ctx = new SP.ClientContext.get_current();
this.web = ctx.get_web();
ctx.load(this.web);
ctx.executeQueryAsync(Function.createDelegate(this, this.onSuccess),
Function.createDelegate(this, this.onFail));
}
function onSuccess(sender, args) {
alert('web title:' + this.web.get_title() + '\n ID:' + this.web.get_id() +
'\n Created Date:' + this.web.get_created());
}
function onFail(sender, args) {
alert('failed to get list. Error:'+args.get_message());
}
</script>
Load minimal data if need:
ctx.load(this.web,'Title','Id','Created');
Execute your JavaScript function after sp.js is loaded:
- ExecuteOrDelayUntilScriptLoaded(myjsfucntion, "sp.js");
Update with ECMAScript Library:
<script type="text/javascript">
function updateTitle() {
var ctx = new SP.ClientContext.get_current();
this.web = ctx.get_web();
web.set_title('UpdatedTitle');
this.web.update();
ctx.executeQueryAsync(Function.createDelegate(this, this.onUpdate),
Function.createDelegate(this, this.onFail));
}
function onUpdate(sender, args) {
alert('title updated');
}
function onFail(sender, args) {
alert('failed to update title. Error:'+args.get_message());
}
</script>
Deployment Consideration
SharePoint provides two sets of JavaScript file: minified and
unminified/debug version.
- sp.js file is minified
- sp.debug is minified and debug version.
The default master page in
SharePoint has a scriptmanager in the page and whose ScriptMode is set
to auto, as a result the minified version of js file loaded. If you want
to use debug version you can add the
<deployment retail="false"
/> in the <system.web> section of the web.config.
The ECMAScript supported in the following browsers:
- Microsoft Internet Explorer 7.0 or greater.
- Firefox 3.5 or greater
- Safari 4.0 or greater
