Microsoft SharePoint Team Blog

using System;

using System.Web.UI;

using System.Web.UI.WebControls.WebParts;

using Microsoft.SharePoint;

namespace Litware.NGWebParts

{

    /// <summary>

    /// An example web part

    /// </summary>

    public class SocialAnnouncentsWebPart : SharePoint.Ajax.WebParts.XmlWebPart

    {

        protected override void CreateChildControls()

        {

            base.CreateChildControls();

            // Include the NewsGator socialsites runtime-- includes the Social Sites JS files:

            this.Controls.Add(

                new NewsGator.Enterprise.SharePoint.WebParts.ClientRuntimeControl()

                );

            // Add the Litware Social script library:

            this.AtlasScriptManager.Scripts.Add(

                new ScriptReference("/_layouts/Litware/LitwareSocial.js"));

        }

        /// <summary>

        /// Use this to set the XML/XSLT paths, typically from Web Part properties.

        /// </summary>

        protected override void OnPreRender(EventArgs e)

        {

            base.OnPreRender(e);

            this.XmlUrl = SPContext.Current.Web.Url +  "/list.rxx?feed=announcements";

            // Usee a custom XSLT

            this.XsltUrl = "/_layouts/Litware/XSLT/announcements.xslt";

        }

    }

}

Using this same approach, you can build custom versions of many NewsGator Social Sites data objects that are exposed as XML; including the Social Profile (an extension of the SharePoint User Profile), a syndication subscription list, communities that users are members of, tag clouds, or syndicated feeds of SharePoint content or of content from other RSS enabled data sources. Security is implemented throughout the NewsGator code that runs in SharePoint as well as the NewsGator Enterprise Server, which is the feed server that provides RSS, ATOM, OPML, and tagging for various data sources. Our API includes the following XML feeds, all of which are implemented in various web parts and AJAX controls in Social Sites: subscription list, SharePoint list feed, reading list (a group of internal and external feeds scoped to the SharePoint site level and available through OPML or a single aggregated feed), colleagues, SharePoint user profile data, site feeds (OPML for the SharePoint's syndicated feeds), trending data, and more. One of our favorite "easter egg" endpoints is Lawrence Liu's OPML, which contains a list of feeds that he maintains for the worldwide SharePoint community. The OPML is available publicly at http://services.newsgator.com/sharepoint/opml, but it's also available within the SharePoint context via Social Sites as the local endpoint: ll.opml.nges.

All of our service endpoints run within the SharePoint application to integrate with SharePoint's site context and security and also to enable AJAX integration from the Microsoft AJAX Library. Since we use the SharePoint AJAX Toolkit as our user interface library, we're able to implement and reuse most of our rendering/presentation logic through common XSLT files. Hence, we can focus more of our development efforts on creating the backend services utilizing SharePoint's API. This lets us quickly roll out new features by exposing new endpoints and writing a minimal script library. For example, the AJAX forums components that we're shipping in Social Sites 2.0 utilize the SharePoint Discussion Lists as the backend services. SharePoint provides a great foundation for custom applications by providing the security context, site context, and data storage, while its APIs make it easy to integrate custom solutions on top of the platform.

NewsGator Enterprise Server has had one of the best feed readers in the market. Adding the feed reader into SharePoint to provide a seamlessly integrated user experience just made sense—so in Social Sites 2.0, we're introducing the My Feeds reader, which brings all of your feed subscriptions into a single view within SharePoint. Here's a screenshot:

Integrating the reader was simple with the help of the SharePoint AJAX Toolkit and the APIs we already exposed—we simply transform the OPML of feed sources including your subscriptions or SharePoint site feeds, and then use the JavaScript API method SPNGES.NewsReader.Read(xmlUrl) to instantiate the reader. We implemented the reader with the following components:

• A SharePoint ASPX page deployed as a Feature.
• The existing Social Sites OPML and RSS API endpoints to enable feed lists and RSS content views.
• Custom JavaScript for paging, resizing images, and social metadata.

Extending Team Sites for Social Sites Communities

SharePoint sites are a great way for people to come together to collaborate on a project, activity, or pretty much anything. When we wanted to implement online communities in Social Sites — an extension of the SharePoint team site just made sense. To create communities, we extended the team site with community metadata and integrated membership with NewsGator Enterprise Server, enabling group collaboration through community tagging, social bookmarking, and feed item interaction. We also integrated some custom web services for community interaction and made them available to the JavaScript API.

Before we talk about the technical implementation, here's a screenshot of a community straight from our Social Sites "dogfood" environment at NewsGator:

To implement the community functionality, we decided to create pages within a Feature that we could include in a site definition or access programmatically. So every tab in the community — Overview, Discussions, Feeds, Social Bookmarks, Members, and Documents — became a page that integrated a set of AJAX components pulled from our existing API. Here's what the CommunityPages development project structure looks like in Visual Studio — note that we're also using a Feature Receiver, so we can process the community on the server as well:

We also wanted to give our customers a way to extend the community functionality. While you can associate Features with site definitions, there isn't an out of the box way to associate Features with other Features. To address this and let our customers extend the community Feature, we came up with a Feature Stapling technique that lets customers implement custom Feature Receivers that are added onto our base Feature. To do this, we look for a Feature that has the feature name of our feature plus the ".Handler" extension. This lets our customers do anything they want to the community Feature such as adding pages, web parts, lists, or whatever else through the Feature Receiver. Here's the code for our Feature Stapling technique — feel free to leverage this in your own custom SharePoint applications: