SharePoint Blog

Search Content Web Part for SharePoint 2010 (Sandbox)

Every since I learned about SharePoint 2013′s Content Search Web Part, I thought “Hey, that’s easily done with SharePoint 2010 as well!”. This weekend I finally managed to put my head down and do some creative programming. But of course, as this is the Age of Apps, I wanted to create a lightweight (a.k.a. a sandboxed) solution. Below, you’ll find a first screenshot of what I came up. It gives a rather good first impression of what the Search Content Web Part for SharePoint 2010 can do (for you).

Image

Click image to enlarge

So what can it do? The basic idea of the Content Search Web Part is simple yet effective: Define and execute a search query and go and fetch for each result the corresponding item with its wealth of information, which is subsequently merged into an attractive grid-like layout. This cannot be achieved with the out-of-the-box Core Search Result Web Part simply because SharePoint’s Search Application doesn’t return enough information. Let me try and explain, using the example shown in the previous screenshot. Here, for instance, information found in SharePoint Publishing Pages is used to build an attractive layed out UI element. I’ve used cupcakes (many thanks to the guys over at http://www.cupcakeipsum.com; It’s such a tasteful alternative to regular lorem ipsum) but in real-life this can be the latest Corporate or Departmental News. Links to those pages were returned as a result from a keyword based search query for “Cupcake AND Brownie”. The seach query was further enhanced to search within the “All Sites” scope and to only return items of a specific content class (in this case: STS_ListItem_850, which corresponds to SharePoint Publishing Pages). But page content, rollup images, last modified dates etc. of course are not part of the results that were returned. So this is where the Content Search Web Part starts to do more than the out-of-the-box Search Core Results Web Part. Doing more, in this case, means fetching additional (item) information for each search result. With the detailed information available, the Content Search Web Part starts merging it into an attractive template (e.g. an HTML/CSS snippet). The outcome of this step is then placed in a grid-layout that is defined by a number of results per row and a maximum number of items that should be returned in the first place. To beautify the final result, an external CSS file (for example uploaded to the site’s Style Library) can be linked to the Web Part.

A couple of benefits of this approach …

  • It pulls together data across multiple SharePoint Sites, Site Collections and even Web Application
  • It’s lightweight i.e. you don’t need to ask the administrator to install it. Instead, it’s sufficient to have Site Collection Administrator rights.
  • It’s easy and intuitive to configure.
  • Templates can be defined using industry standards such as HTML and CSS
  • It doesn’t create any dependencies when upgrading to the next version (then it can be replaced by SharePoint 2013′s out-of-the-box Content Search Web Part)

A closer look …

To create a sandboxed web part I could have opted for SharePoint’s Client Object Model. But I didn’t. Instead I choose for a client-side jQuery approach that would query SharePoint’s web services. This means that the server (SharePoint) needs to exchange information e.g. settings with the client (Browser / jQuery). Under the hood, when the web part is loaded, this is achieved by using a number of hidden form fields. All the settings entered by the user into the web part’s editor (see screenshot below) are hence available to the client once the user applies his configuration.

Image

With this information available, the client invokes a query to SharePoint’s Search Query Web Service (<your site>/_vti_bin/search.asmx). For each search result that is found in the response of SharePoint’s Search Query Web Service, the client continues querying SharePoint’s Lists Web Service (<search result’s path to item’s site>/_vti_bin/lists.asmx) to get the list item for each result using the PATH property found in search result. Unfortunately, this may result in the client trying to obtain a list item e.g. an Announcement or a Publishing Page of a SharePoint site that resides in a different Web Application. So the client basically tries to invoke a query across different domains and this is not allowed (known as XSS or cross-site scripting). However, jQuery (as of version 1.6) provides a work-around. But this work-around shows a warning to the user that a cross-domain query is about to be invoked: “This page is accesssing information that is not under its control. This poses a security risk. Do you want to continue?”.

Image

Cross-domain queries can be surpressed by deselecting “Allow queries to other web applications”. When surpressed, any query to another web application fail and hence the results will fail in the final output.

Defining item fields …

Each search result returned from SharePoint’s Search Query Web Service itself doesn’t contain a whole lot of information. But it provides a PATH property that can be used to locate the item in SharePoint. Knowning the item’s location, its information stored in fields (= columns) can easily be retrieved using SharePoint’s List Web Service. However, at a lower level, SharePoint uses field names that are differ from the column names visible in the UI. Once a valid search Query was defined and tested (by clicking Apply in the web part editor panel) the raw XML output can be viewed. This helps to find the names of the fields (colored red) that contain the information that can be merged into the template. The following screenshot is an example of such output.

Image

Click image to enlarge

Remark The Content Search Web Part will try to automatically change relative URLs (like ows_PublishingRollupImage in the example above) into absolute URLs.

Field names can then be entered into the web part’s editor panel separated by a semi colon e.g. “ows_PublishingPageContent;ows_PublishingRollupImage” (without quotes). In addition, it is possible to limit the number of characters returned. This limit can be entered between square brackets immediately following the field name as follows: “ows_PublishingPageContent[400];ows_PublishingRollupImage”. This will cause the text to be shortened to the first 400 characters. It will then cut off at the end of last word and add a read-more link. When the user click’s this link, he/she will be taking to the original item. A close-up look is shown in the following screenshot.

Image

Remark The markup e.g. “<p><span class= ng-dire…” is ignored when the content is shortened. Only the text within the HTML markup is used.

Creating the Template …

The Template Editor isn’t a highly advanced editor. But it is sufficient for pasting any HTML snippet created in a full-blown editor. The template is for laying out a single item i.e. not for laying out the whole result set returned. The idea behind this is that each item is the basically same by definition. Only the content is different. The Search Content Web Part then takes care of laying out items according to the grid that the user defined i.e. number of items per row and total number of items that should be returned.

Image

Click image to enlarge

Content for each field that was retrieved is can be easily placed into the Template using a wiki-like notation e.g. for “ows_PublishingPageContent” use “[[ows_PublishingPageContent]]” (again, no quotes). The cupcake example that I used uses the following (simple) template:

<div>
<div id=”CSWPNewsItemHeader”>
<div id=”CSWPNewsItemTitle”>
[[ows_Title]]
</div>
<div id=”CSWPNewsItemModified”>
[[ows_Modified]]
</div>
</div>
<div id=”CSWPNewsItemBody”>
<div id=”CSWPNewsItemContent”>
[[ows_PublishingPageContent]]
</div>
<div id=”CSWPNewsItemRollupImage”>
[[ows_PublishingRollupImage]]
</div>
</div>
</div>
</div>

Understanding the grid-layout and CSS …

The Search Content Web Part places each merged output into it’s own DIV that is then placed into another DIV (=ROW) that eventually resides inside another DIV (=Container). However, there is one challenge with this setup: the width property of the DIV that holds the merged outcome. Most of the CSS that defines the setup of the grid i.e. the container, rows and row items is defined in a CSS file that is automatically placed inside the Style Library in a separate folder CSWP (here you also find the javascript files used by the Content Search Web Part) called CWSP.css. In addition, you can specify your own CSS file with CSS instructions for you template. For a good result, you need to include the following CSS instruction:

#CSWPContentItem
{
width: 48%;
display: inline;
padding: 5px;
margin: 0px;
float: left;
}

This statement is for the box that frames the template. In my example I specified that I want 2 items per row. Hence I’ve specified a width property of 48%. If you want only 1 result per row, you need to specify it with a width of about 98% or 99%.

Error handling …

Errors are handled in a SharePoint friendly manner. The following screenshot show the error that is raised when the search scope is omitted.

Image

Click image to enlarge

Requirements …

Downloading …

Feel free to download Search Content Web Part using the following link: http://www.sharepointconsultant.ch/wp-content/uploads/2013/03/WebParts.zip (rename extension from ZIP to WSP e.g. WebParts.WSP)

It will show a little banner at the bottow as follows:

Image

Click image to enlarge

Feel free to make a donation (http://www.sharepointconsultant.ch/donate/ ) if you like it. In that case I happily send you a copy without banner!

Installing …

1. Upload WSP file to the site’s solution gallery

Image

Image

2. Activate uploaded solution

Image

3. Add Content Search WebPart to the page

Image

Copyright ©2012. All Rights Reserved.