4

Closed

Implement SharePoint 2010 Client Object Model Support

description

Hi,

First, let me say thanks for building this library! I'd really go insane building XML CAML queries without it.

We've been working with the SharePoint Client Object Model for our application and whilst Camlex.NET does a great job of creating basic queries we also wanted to use the .ViewFields functionality. So we've made some small changes do the latest source code to adapt it to this purpose (source code attached to this work item).

The following (high level) changes were made:
  • Microsoft.SharePoint references were changed to Microsoft.SharePoint.Client
  • SPListItem type dependencies were updated to ListItem
  • Modified .ToCaml() to only output XML with a surrounding <View> and <Query> elements (since CamlQuery.ViewXml needs this) (and updated the existing unit tests)
  • Modified .ViewFields methods to return IQuery rather than string (and updated the existing unit tests)
  • Modified .ToCaml to also output the <ViewFields> element (and updated the existing unit tests)
  • Commented out unit tests that test for Guid functionality (ListItem.this[Guid] doesn't exist in the Client Object Model)
  • Commented out unit tests that test for int support (ListItem.this[int] doesn't exist in the Client Object Model)
  • Commented out unit tests that test for specific field Id (the SPBuiltInFieldId class does not exist in the Client Object Model)
These changes allow us to write code like...

Camlex.Query().ViewFields(l => l["Title"]).Where(l => (string)l["Title"] == "FooBar");

and get a query that will work with CamlQuery in the managed client object model:

<View>
<ViewFields>
<FieldRef Name="Title" />
</ViewFields>
<Query>
<Where>
  <Eq>
    <FieldRef Name="Title" />
    <Value Type="Text">FooBar</Value>
  </Eq>
</Where>
</Query>
</View>

So, the point of this work item is to really propose that Camlex supports the Client Object Model out-of-the-box. The changes required are actually quite minor although the differences around ViewFields are definitely incompatible. I'm not suggesting that you use the code that I've provided (I haven't put any effort into having the same assembly support both the COM and Server APIs) but it does demonstrate how little work is required.

Hopefully you guys have the time do to this.

Cheers,
Scriv

file attachments

Closed Oct 13, 2012 at 7:57 AM by sadomovalex
Client object model support is implemented

comments

sadomovalex wrote Jul 16, 2011 at 8:15 AM

hi Scriv,

thanks for your input and especially for the code. We have plans to adopt Camlex to Silverlight. Your help with Client Object Model is great - it will be definitely used. But it will be 3 releases instead of one (common Sharepoint , Silverlight, Client OM). Need to think how to manage it so it won't be misleading.

With ViewFields() we used string intentially - because in SPQuery there are 2 different properties (Query and ViewFields) and it doesn't have sense to make one methods chain for them as they should be called separately. Also keeping in mind the known problem that only last call will be used (e.g. .ViewFields(x => x["Title"])).ViewFields(x => x["ID"] - ID will be used) we decided to return string. But for Client OM it have sense.

kenny wrote Oct 3, 2011 at 7:21 AM

Any news on the Client Object Model support?

sadomovalex wrote Oct 3, 2011 at 7:11 PM

hi kenny,
it will be planned to future release, but not in the nearest one. In my opinion this feature already has crucial mass to be next after next release. Will discuss it with Vladimir.

stefh wrote Jul 30, 2012 at 9:06 PM

Hi Sadomovalex,

I'm very charmed by the ClientObjectModel solution as written by Scriv.

Can you maybe use some help by adding this solution to you existing solution ? I am thinking of creating a Camlex.NET.Common library which contains common functionality which can be shared by the 3 projects.

Please give feedback.

Best regards,
Stef

sadomovalex wrote Aug 20, 2012 at 9:18 PM

hi stefh,
thanks for your interest for the project. Sorry for the late reply - was offline in vacation. There is an option to create separate branch for that and manage releases of client part separately. We can consider to add you to contributors if you want to work on that. I think it will be better option than have separate project on codeplex. In this case we will coordinate releases instead of doing it independently. As result I believe we will get better quality. If you are interested, please notify me.

stefh wrote Aug 27, 2012 at 12:01 PM

I've send you an email to your Gmail address, please check.