John W Powell : Windows SharePoint Services

Subscribe to SharePoint Web Parts using Internet Explorer 8 Web Slices

johnwpowell — Mon, 02 Feb 2009 00:34:00 GMT

One of the new features of Internet Explorer 8 is Web Slices. This feature enables you to subscribe to a section of a web page and notifies you when the content changes. By design, SharePoint Web Parts are a natural fit for this feature, and in this article I’ll show you how to build a Web Part that does just that. I’ll also show you how easy it is to develop a web part using the CTP release of Visual Studio 2008 Extensions for Windows SharePoint Services (VSSWse) 1.3.

About Web Slices

Web Slices enable you to have a very narrow control over the content you subscribe to. When you browse a page that has Web Slice sections, they “light up” when you hover over them:

In addition, the new Web Slice icon on the toolbar lights up, and the menu is populated with all the slices on the page:

When you subscribe to a slice, the web page section is added to the toolbar and is periodically refreshed. The refresh interval is completely customizable and can also be refreshed manually:

Defining a Web Slice Section

Web Slices are defined with HTML tags that have certain CSS classes. You can read the full specification, but here’s all you need to know to build your first Web Slice:

To define a Web Slice section, use the hslice class name:

<div class="hslice" id="1">…</div>

To define the slice title, use the entry-title class name:

<p class="entry-title">Game System - $66.00</p>

To define the slice content, use the entry-content class name:

<div class="entry-content">This auction closes in 4 hours.</div>

The end result looks like this:

<div class="hslice" id="1">

<p class="entry-title">Game System - $66.00</p>

<div class="entry-content">This auction closes in 4 hours.</div>

</div>

Build a SharePoint Web Part

For this example, I’m using VSSWSE 1.3 which you can read about here. I would recommend it not only because it’s easy to use, but also because it is sure to become the de-facto standard. To get started, create a new Web Part project:

Choose if you want to deploy to the GAC or bin directory. We’ll use GAC for this example:

A solution is created with a default web part named WebPart1. Rather than renaming it, delete the WebPart1 folder and add a new Web Part to the project with a more descriptive name:

Next, configure the url of your SharePoint site you want to use to test the Web Part. On the Debug settings, set the start url:

In the Web Part, override the CreateChildControls method:

This code generates the needed HTML and is pretty self-explanatory. I chose to hide the Web Slice entry-title as it would be redundant beneath the Web Part title. To test the code, right-click the solution or project and select Deploy. This will package the Web Part as a feature and deploy and activate it on the site:

Next, add the Web Part to a page in the site and test it.

How I Wished It Worked

Web Slices are powerful, but I don’t really want to develop a bunch of new Web Parts to use that feature. I wish every Web Part were capable of wrapping its content in a Web Slice div tag. I’m sure there is a way to inject this functionality (and there might even be a supported method), but I wish it were built in to the Web Part framework. Every Web Part could then have a Web Slice category with relevant settings:

Wouldn’t that be powerful?

Summary

In this article, I demonstrated how to build a Web Part that users can subscribe to using Web Slices. I also showed you how easy it is to build a Web Part using the CTP release of Visual Studio 2008 Extensions for Windows SharePoint Services version 1.3. Happy slicing!

References and Additional Reading

Build PowerShell CmdLets to call SharePoint Web Services using WCF

johnwpowell — Mon, 03 Nov 2008 00:22:00 GMT

In this post I'll show you how to build a PowerShell cmdlet that consumes SharePoint web services using WCF. What I like about this approach is that it provides the ability to use some of the SharePoint API without having to be logged in to the SharePoint server. Although you can accomplish the same thing using PowerShell scripts and functions, in this post we'll build a SharePoint cmdlet using C#.

About the Approach

There are several advantages of combining PowerShell and SharePoint web services:

Consume the SharePoint API without logging on to a SharePoint server
Provide a layer of abstraction and reusable task-oriented building blocks
Reduce risk of performance issues caused by PowerShell scripts that don't dispose of unmanaged SharePoint resources

There are also some drawbacks to writing custom cmdlets that consume SharePoint web services:

SharePoint web services do not expose the full API; you may need to augment them with business-specific functionality
Cmdlets require compilation and additional overhead over script file

Getting Started

In this walkthrough, I'm using Visual Studio 2008 on a SharePoint virtual machine. Although you could use a Visual Studio PowerShell project template, we'll are going to build everything by hand so there are no mysteries. So let's get started by creating a new class library project:

Add a reference to PowerShell which is contained in System.Management.Automation assembly. If you've installed the Windows SDK, you can find it in the following location: C:\Program Files\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0

Since we are creating a class that will both describe and install a custom snap in, we need to reference System.Configuration.Install

Create the Snap In and Cmdlet

Add a new class that inherits CustomPSSnapIn. Add the RunInstaller attribute to the class and describe the snap in by overriding the Name, Vendor and Description properties. Your code should end up looking like this:

Add a new class that inherits from Cmdlet. We'll build a cmdlet to get information about a SharePoint site, so name it "GetSPWebCmdlet." Add the Cmdlet attribute to the class. You'll notice the cmdlet name, "Get-SPWeb" is a combination of the noun string SPWeb and verb enumeration VerbsCommon.Get specified by the Cmdlet attribute:

Override the Cmdlets property in the snap in class and add the Get-SPWeb cmdlet to the Cmdlets collection:

Configure Visual Studio to Install and Add the Snap In When the Project is Debugged

Before we add any code to the cmdlet, let's configure Visual Studio to automatically deploy the snap in to make debugging easier. We'll use a post-build event to install the snap in, so in the spirit of learning PowerShell, we'll write the post-build script in PowerShell! Add a new text file to your project named PostBuildEvent.ps1. Add the following script to the file:

trap
{
   $errorTxt = $_.Exception.Message
   write-output "$errorTxt"
   break
}

$targetDir = $args[0]
$targetFileName = $args[1]
$snapInName = $args[2]

write-output "Deploying..."
join-path $targetDir $targetFileName
write-output "Snap In Name: $snapInName"

set-location $targetDir
set-alias installutil $env:windir\Microsoft.NET\Framework\v2.0.50727\installutil
installutil $targetFileName

Notice the script file takes some arguments (targetDir, targetFileName and snapInName). Using that information, it installs the SnapIn (and our SharePoint cmdlet). Configure Visual Studio to pass the arguments to the post-build event:

After a SnapIn is installed, you have to add it to your environment before it can be used. As you can see, even though our custom snap in has been installed, it is not listed when you call Get-PSSnapin:

To add it, call Add-PSSnapin passing in the name of the assembly:

We don't want to add the snap in after each code change, so we are going to automate it by adding a console file that will add the snap in into our environment when the project is debugged. Add a new file named SharePointSamples.Console.psc1 to your project. Put the following xml in the file:

<?xml version="1.0" encoding="utf-8"?>
<PSConsoleFile ConsoleSchemaVersion="1.0">
<PSVersion>1.0</PSVersion>
<PSSnapIns>
<PSSnapIn Name="SharePointSamples.PowerShell" />
</PSSnapIns>
</PSConsoleFile>

In the project configuration, Debug settings, configure Visual Studio to start PowerShell when you debug and in the command-line arguments section, use the -PSConsoleFile argument to specify the console file you created:

Implement the Cmdlet

Now that deployment and debugging are taken care of, add the following code to the cmdlet:

The cmdlet takes the url of the site as an argument. Arguments are implemented as class properties decorated with the Parameter attribute. The work is implemented in the ProcessRecord method. As you can see, I already did some re-factoring and created a service locator class that will give me an instance of the SharePoint Webs service (using WCF). The code then invokes the GetWeb method and writes out the resulting xml.

Here is the code for the service locator. As you can see it configures the SharePoint Webs proxy:

Most of the key WCF configuration settings for integrated authentication are implemented in the BindingFactory class:

Test the Cmdlet

To test the cmdlet, run the project. When the PowerShell command prompt opens, type Get-SPWeb. You will be prompted for the site url if you don't provide it:

Summary

In this walkthrough, you learned how to leverage PowerShell, WCF and the SharePoint web services to implement a custom cmdlet. Using this approach, you can expand the administrative capabilities of SharePoint and build reusable, task-oriented building blocks to increase your productivity and capability.

Get the code for this article.