Home

Buscar

Tuesday, January 21, 2014

SharePoint Search From a Client Application

Search from Client Application

Using the Query Web Service

SharePoint Query Web Service

Microsoft.Search.Query Schema

Microsoft.Search.Query Schema

Bookmarks

SharePoint is awesome...


Queries and Data Retrieval in SharePoint Foundation
Querying from Server-side Code
Querying from Client-side Code
Query SharePoint Foundation with ADO.NET Data Services
DspSts Web Service ()
LINQ to Objects
SharePoint 2010 Client Object Model

FAST

The two Enterprise Search options in Microsoft SharePoint Server 2010—Microsoft FAST Search Server 2010 for SharePoint and Microsoft SharePoint Server 2010 search—are designed to share a common platform to enable search solution developers to use the same query-side interfaces.
Developers can take advantage of the same object models, services, and a common query language instead of having to learn new APIs or programming models.


Wednesday, January 15, 2014

Site pages vs Application pages

Site pages are pages that are created, edited, and customized by end users. They are primarily used for the content in a site. Site pages come in two types—a standard page and a Web Parts page. A standard page contains text, images, Web Parts, and other elements. A Web Parts page contains Web Parts in Web Part zones. They have a predefined layout that uses Web Part zones. Both types of site pages are edited using a Web browser or Microsoft SharePoint Designer.
Site pages are provisioned from a template page that is stored on the file system of the front-end Web server. When a site is provisioned, SharePoint Foundation creates a pointer to the instance of the page template on the file system. This allows SharePoint Foundation to avoid repeatedly creating copies of the pages, which are provisioned each time a site is created.
When a user customizes a site page, the template for the page is then stored in the content database. The page is retrieved from the content database every time it is requested by a user. A customized page can, however, be reset to the original template page through the Web browser or a tool such as SharePoint Designer.
Application pages are used to support application implementations in SharePoint Foundation. Application pages are stored on the file system of the front-end Web server in the %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS directory and exist for every site in a Web application. This folder is mapped to an Internet Information Services (IIS) virtual directory called _layouts. Every site and subsite will have access to the application pages by using the _layouts virtual directory. For example,http://myserver/_layouts/settings.aspx and http://myserver/subsite/_layouts/settings.aspx access the same application page on the front-end Web server unlike site pages, which are an instance for the specified site.
Application pages are not subject to the same restrictions as site pages. They allow in-line code without restriction. They cannot, however, use dynamic Web Parts or Web Part zones or be modified using SharePoint Designer. Modifying the default application pages is not supported in SharePoint Foundation. Custom application pages can be added to a subdirectory inside the _layouts folder.

Thursday, December 26, 2013

Client Object Model with the Open XML SDK


The Microsoft SharePoint Foundation 2010 managed client object model enables you to write applications that are based on the Microsoft .NET Framework that access SharePoint content from clients without installing code on the server that runs SharePoint Foundation 2010. 


The Open XML SDK 2.0 for Microsoft Office enables you to write applications to create, change, and query Open XML documents, the default document format for the Microsoft 2007 Office system and Microsoft Office 2010. By using these two technologies together you can write client-side applications that work with Open XML documents that are stored in document libraries.

more @ Using the SharePoint Foundation 2010 Managed Client Object Model with the Open SDK


asynchronous processing


using System;
using System.Collections.Generic;
using Microsoft.SharePoint.Client;

class Program
{
    static void Main(string[] args)
    {
        AsynchronousAccess asynchronousAccess = new AsynchronousAccess();
        asynchronousAccess.Run();
        Console.WriteLine("Before exiting Main");
        Console.WriteLine();
        Console.WriteLine("In a real application, the application can");
        Console.WriteLine("continue to be responsive to the user.");
        Console.WriteLine();
        Console.ReadKey();
    }
}

class AsynchronousAccess
{
    delegate void AsynchronousDelegate();

    public void Run()
    {
        Console.WriteLine("About to start a query that will take a long time.");
        Console.WriteLine();
        ClientContext clientContext =
            new ClientContext("http://intranet.contoso.com");
        ListCollection lists = clientContext.Web.Lists;
        IEnumerable<List> newListCollection = clientContext.LoadQuery(
            lists.Include(
                list => list.Title));
        AsynchronousDelegate executeQueryAsynchronously =
            new AsynchronousDelegate(clientContext.ExecuteQuery);
        executeQueryAsynchronously.BeginInvoke(
            arg =>
            {
                clientContext.ExecuteQuery();
                Console.WriteLine("Long running query completed.");
                foreach (List list in newListCollection)
                    Console.WriteLine("Title: {0}", list.Title);
            }, null);
    }
}

How the Client-Side Object Model Works


How the Client-Side Object Model Works
An application that uses SharePoint content interacts with the API in several ways—call methods and get the return values, pass a Collaborative Application Markup Language (CAML) query and get the results, and set or get properties. After you use the API to perform a specific task the SharePoint Foundation 2010 managed client object model bundles up these uses of the API into XML and sends it to the server that runs SharePoint Foundation. 
The server receives this request, and makes appropriate calls into the object model on the server, collects the responses, forms them into JavaScript Object Notation (JSON), and sends that JSON back to the SharePoint Foundation 2010 managed client object model. The client object model parses the JSON and presents the results to the application as .NET Framework objects (or JavaScript objects for JavaScript). The following diagram shows these interactions.


It is important to be aware that you control when the SharePoint Foundation 2010 managed client object model starts to send the XML to the server and receives the JSON back from the server.

Client Class Library

Name
Description
Core namespace that provides types and members for working with SharePoint Foundation Web sites, list data, and users within a site collection.
Provides types and members for encoding strings, for working with security principals, and for performing specific utilities tasks.
Provides types and members for managing Web Parts within Web Parts pages.
Provides types and members for managing workflow templates and workflow associations.

The members of the Microsoft.SharePoint.Client.Application namespace are reserved for internal use and not intended to be used directly from your code.

Client-side classes and server-side equivalents

Client
Server


Notice that the SharePoint Foundation 2010 managed client object model uses the same legacy naming pattern for site collections and sites as the server object model. 

The Site class represents site collections, and the Web class represents sites. 

My preference for using these classes is to name the variables so that the variable name indicates whether it is a site collection or a site, even though you must use the Site and Web classes to declare them.

The following example shows how name variables.

C#
ClientContext clientContext = new ClientContext(siteUrl);
Site siteCollection = clientContext.Site;

Web site = clientContext.Web;

Namespaces in the JavaScript Object Model

==========================================================================
Namespace                                                                         JavaScript File
==========================================================================
CUI Namespace                                                                CUI.js, SP.UI.Rte.js
CUI.Controls Namespace                                              CUI.js
CUI.Page Namespace                                                     CUI.js, SP.UI.Rte.js
SP Namespace                                                                  SP.Core.js, SP.js, SP.Ribbon.js, SP.Runtime.js
SP.ListOperation Namespace                                       SP.Core.js
SP.Ribbon Namespace                                                  SP.Ribbon.js
SP.Ribbon.PageState Namespace                              SP.Ribbon.js
SP.UI Namespace                                                            SP.Core.js, SP.js, SP.UI.Dialog.js
SP.Utilities Namespace                                                  SP.Core.js, SP.js, SP.Exp.js
SP.WebParts Namespace                                              SP.js
SP.Workflow Namespace                                              SP.js
==========================================================================

Saturday, December 14, 2013

LINQ to SharePoint Provider

The gateway class for the LINQ to SharePoint provider is Microsoft.SharePoint.Linq.DataContext which represents the data of a SharePoint Foundation Web site. 

It is parallel in use and function to the System.Data.Linq.DataContext class in the LINQ to SQL provider. 

Just as the latter class has a GetTable() method that returns a Table<TEntity> object that implements System.Linq.IQueryable<T>, so too, the Microsoft.SharePoint.Linq.DataContext class has a GetList<T>method that returns an EntityList<TEntity> class that implements System.Linq.IQueryable<T>

It is objects of type EntityList<TEntity> that are queried.

The following is an example of the use of LINQ to query SharePoint Foundation.


// Get DataContext from page context
DataContext data = new DataContext(SPContext.Current.Web.Url);

// Get the SharePoint list
EntityList<Customer> Customers = data.GetList<Customer>("Customers");

// Query for customers from London
var londonCustomers = from customer in Customers
                      where customer.City == "London"
                      select customer;

foreach (var londonCust in londonCustomers)
{
    Console.Writeline("id = {0}, City = {1}", 
                      londonCust.CustomerId, 
                      londonCust.City);
}



The following is an example of using LINQ to add an item to a SharePoint Foundation list.
// Get DataContext from page context
DataContext data = new DataContext(SPContext.Current.Web.Url);

// Get the SharePoint list
EntityList<Customer> Customers = data.GetList<Customer>("Customers");

// Create the item to be added
Customer newCustomer = new Customer() { CustomerId=36, City=”Madrid” };

// Mark the item to be added on the next call of Submit
Customers.InsertOnSubmit(newCustomer);

// Submit all changes
data.SubmitChanges();

Wednesday, December 11, 2013