Retrieving Data Share Point 2010

As you saw in the preceding code snippets, although the Client Object Model defines clientside representations of server objects and we can create instances of those objects in our code, the objects are not populated with a copy of the server-side data until it is explicitly loaded.

In-place Load

This Silverlight code snippet shows how to execute a Collaborative Application Markup Language (CAML) query against a list:

To perform the same function using JavaScript, you can use this:

The important thing to note about these code samples is the use of the ClientContext.Load method. This method flags the passed in object to be populated the next time ExecuteQueryAsync is called, so in the preceding example, ctx.Load(listItems) will flag the listItems object for population.

To use these code snippets with the demo project that we set up earlier, take the following steps—first, for the Silverlight sample:

  1. Add a new button labeled Execute CAML Query to MainPage.xaml, and set the
    Click event handler to CAMLQuery_Click.
  2. Add the Silverlight code snippet listed above into MainPage.xaml.cs.
  3. Add a ScrollViewer control to MainPage.xaml and then, inside the ScrollViewer, add a Grid control named grid1.
  4. Add the following code into MainPage.xaml.cs:
  5. Build the SilverlightCOMDemo project.
  6. Now,for the JavaScript sample, do the following:

    1. Using SharePoint Designer, modify JavascriptTest.aspx to include an additional button.
    2. Above the DemoConsole div tag that we added earlier, insert the following markup:
  7. Within the JScriptTest.js file in our SharePoint project, add the CAMLQuery_Click JavaScript sample method listed above and then add the following function:
  8. With these changes in place, by deploying the solution, we can view the results of our CAML query as a table using either the Silverlight test page or the JavaScript test page that we added earlier in the chapter.

Object Identity

Although property values are not populated until they are explicitly loaded, it is still possible to make use of the properties in expressions, as long as the expressions themselves are not enumerated until after the properties are loaded. In our code sample, we can see an example of this in the following line:

List announcements = ctx.Web.Lists.GetByTitle("Announcements");

If we were to attempt to enumerate any of the properties of the announcements object, an error would be thrown since the value has not been initialized. The same is also true of the properties of the object referred to by the ctx.Web property. We can use the property in an expression because an expression uses a reference to the property rather than its actual value.
You can see that our code sample makes use of the announcements object in various places, but we never explicitly populate it. Loading an object is necessary only if its properties will be converted to a value. One easy way to look at it is to consider that each object is a proxy for an appropriate server-side object. Using the proxy, we can perform many of the same actions, but until we explicitly load data from the real object into the proxy, we can’t use the data on the client side because it exists only on the server.

Filtering Returned Data

When we execute the preceding code samples, a table is generated containing the field values that are returned for each list item, as shown:

Filtering Returned Data

This works well and doesn’t present much of a problem when only a few items are included in the list or library. But what happens if tens of thousands of items are included and we need only one or two columns? Transferring all this redundant data to the client would have a major performance impact. Thankfully, we can eliminate redundant data by filtering the properties that are populated by the Load method, as the following snippets show. To see the results of these samples, create a new button and hook up the Click event to the sample code, as we’ve done in the past few samples.
Here’s the snippet in Silverlight:

And thre’s the JavaScript:

In the Silverligt sample, we’re making use of lambda expressions and Language Integrated Query (LINQ) to filter the returned data. (If you’re unfamiliar with LINQ or lambda expressions, see Chapter 14 for more information.) Because LINQ syntax isn’t supported by JavaScript, we’re using a string containing a filter expression. When creating JavaScript filter strings, LINQ operations such as Where are not supported.
You can see that by running these samples, the resulting table contains only the Title column. Although you can’t see it from the output, the population of the fields collection has been filtered to include only the properties that are required for the logic. The result of these changes is that the data exchanged between client and server is greatly reduced.

NOTE When querying lists or libraries, you need to be aware of how filtering is applied behind the scenes. First, the CAML query object passed into the GetItems method is used to retrieve a list of items into memory. With the item list in memory, LINQ to Objects is used to apply the filters that we’re defining with the Load method. This is significant, because when you’re querying large lists,item-level filtering should always be done using CAML to reduce the memory usage on the server restrictions are imposed on the number of items that can be retrieved from a list in a single query.

Queryable Load

In addition to the ClientContext.Load method used in the preceding examples, the Client Object Model also provides a ClientContext.LoadQuery method. The difference between these two methods is in the object that receives the results of the method. When calling Load, we’ll pass in a reference to the object that we want to load along with any filtering expression; when the method has executed, that object that we passed in is loaded with the appropriate data. With LoadQuery, when the method has executed, an IEnumerable(T) collection is returned.
You may be wondering about the benefits of such a subtle difference between these methods. The main benefit is that LoadQuery can accept a LINQ query as a parameter; also, the results returned can be further processed using LINQ. In the preceding Silverlight example, we could replace this

In the second example, the fields variable contains an IEnumerable<Field> bject as opposed to the FieldCollection object that would be populated with the first example. Although the JavaScript object model also includes the loadQuery method, since JavaScript doesn’t support LINQ, its primary function is to return the results as a separate variable rather than populating the appropriate ClientContext property. Other than that, there is no real benefit to using loadQuery in JavaScript.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Share Point 2010 Topics