Brendon Schwartz Collaborating on SharePoint

Have you ever wanted to redirect a user to your own MySite landing page.  It is very easy to do with a single delegate control.  This will allow your SharePoint sites to have a profile page such as MyDevCow at any location in the site.  This code would run when you click the persons profile and click My Settings

First create a user control with nothing on the page.  Something like the following

<%@ Control Language="C#" Inherits="DevCow.SharePoint.Controls.DevCowUserProfileRedirect,DevCow.SharePoint,Version=1.0.0.0,Culture=neutral,PublicKeyToken= 0528d6137835b00a" %>

Now create the code behind for a user control that receives a userprofile from the user information list.

public class DevCowUserProfileRedirect : UserControl, IFormDelegateControlSource
{
    #region IFormDelegateControlSource Members

    public void OnFormInit(object objOfInterest)
    {
        SPListItem user = objOfInterest as SPListItem;
        if (user != null)
        {
            this.RedirectIfNecessary(user);
        }

    }

    private void RedirectIfNecessary(SPListItem user)
    {
        //Redirect to hard coded site
        SPUtility.Redirect("http://sharepoint.devcow.com/Pages/DevCowProfile.aspx", SPRedirectFlags.Default, this.Context);
    }

    public void OnFormSave(object objOfInterest)
    {
    }

    #endregion
}

Finally create a Feature with an elements manifest that has the delegate control lower than 100.  Make sure to use the ID of ProfileRedirection

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <Control Id="ProfileRedirection" Sequence="50" ControlSrc="~/_controltemplates/DevCow/DevCowMySiteRedirection.ascx"/>
</Elements>

Reading over Liam's post on a good tip for using the Content Query Web Part (CQWP) to connect your XSLT styles by putting a reference in the ItemStyle.xsl file is a good idea, but it still modifies the Out of the Box (OOB) ItemStyle.xsl.  In many cases, in large companies you can't change the OOB files and this file is no exception, especially since your changes would be overwritten by any product that changed the file also.

The approach to use if you are using a different style than the out of the box style is to deploy your own .webpart of the Content Query Web Part that references a different style sheet than the ItemStyle.xsl file.

First let's look at what the .webpart would look like, the change to notice is that we have added an import statement to the supporting XSL element not to the ItemStyle.xsl

           <webParts>
              <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
                <metaData>
                  <type name="Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart, Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
                  <importErrorMessage>Cannot import this Web Part.</importErrorMessage>
                </metaData>
                <data>
                  <properties>
                    <property name="Title" type="string">Custom XSLT Style Content Query WebPart</property>
                    <property name="Description" type="string">Adds other templates to the ItemStyle.xsl</property>
                    <property name="ItemXslLink" type="string">/Style Library/XSL Style Sheets/DevCowItemStyle.xsl</property>
                  </properties>
                </data>
              </webPart>
            </webParts>

The ItemXslLink contains a link to the XSLT file that has the item templates.  Make sure that the XSLT file is available or the webpart will display that it cannot import the XSLT file.  Also notice that the path is relative, so you will need to put your files in the based site collection or you will need a way to update the location based on sub site collections.  I couldn't find a way around this, but maybe the product team will know how.

Now just create your separate file for your XSLT and make sure to add it to you Solution and Feature.

<xsl:stylesheet
  version="1.0"
  exclude-result-prefixes="x d xsl msxsl cmswrt"
  xmlns:x="http://www.w3.org/2001/XMLSchema"
  xmlns:d="http://schemas.microsoft.com/sharepoint/dsp"
  xmlns:cmswrt="http://schemas.microsoft.com/WebParts/v3/Publishing/runtime"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt">
    <xsl:template name="ShowXML" match="Row[@Style='ShowXML']" mode="itemstyle">
        <xsl:for-each select="@*">
            <br />
            Name: <xsl:value-of select="name()" />
            <br />Value:<xsl:value-of select="." />
        </xsl:for-each>
    </xsl:template>
</xsl:stylesheet>

Here is what the drop down would now look like.  Keep in mind if you want all of the ItemStyle.xsl items to show up, you can simply copy them from the ItemStyle.xsl.  This will allow you to manage your customizations and not be impacted during changes to the ItemStyle.xsl.

If you have questions about how to package these files correctly or how they should be deployed, let me know and I can do a quick blog post on that also.

Lawrence Liu Twittered an interesting video by Dan Rasmus on the New World of Work, he talks about Social Computing in the Enterprise as well as why companies might start to add these applications.

Dan's views remind me a little bit about my post Is Social Networking behind in the Enterprise?.  One thing I talk about is the CIOs adding Social Networks for their employees in order to get good employees.

Check out the video: Partner TV: The New World of Work http://blogs.msdn.com/ptstv/archive/2008/04/30/partner-tv-the-new-world-of-work.aspx

Building server side components that can integrate SharePoint and Facebook have some requirements that you must solve before the integration of other components such as web parts can begin.  Some of the major issues that must be solved are where do I store the Application Key/Secret and how can you maintain user authorization per page.

Here is what the flow looks like with the DevCow Facebook web parts.

 First Request to SharePoint page with Facebook web parts

This case may occur when the user logs into a site for the first time or if the users session in Facebook has expired.

• Step1: The user accesses a SharePoint site that has DevCow Facebook web parts on the page.
• Step2: User clicks on Login link for the configured web part
• Step3: New page opens that redirects to Facebook.com login page
• Step4: User enters credentials and logs into Facebook Application
• Step5: Facebook.com redirects to configured web page with DevCow ReceiverFacebookPart web part on page
• Step6: DevCow ReceiverFacebookPart web part stores SessionKey and UserId in User Profile field
• Step7: Login Window closes and original page refreshes with details of user.

Now when the user returns the page will be render with Facebook information and the user will not need to enter their credentials every time they access the page.  With this model, the system will be responsible for keeping the users information secure and not allowing someone to access the information without their permission.

I am aware that there is a web part that is client side and freely available from http://www.litesuite.com/pages/litefacebook.aspx, but I wanted to create server side web parts and not just an IFRAME or javascript.

Building applications that provide Social Networking capabilities is not building integration to Facebook.  Recently I have been working on some web parts that integrate to the Facebook API using a .NET library called the Facebook Developer Toolkit.  When I tell other people that I am working on Facebook web parts I usually get 1 of 2 responses.

1. The first response might be, "Well I don't really care for Facebook and don't see why you would use it in the first place".  Well honestly they are not that polite and respond with words I shouldn't repeat.
2. Second I hear, "I know someone that is building some Facebook web parts".

Let's just assume for the first response that you understand why you would integrate SharePoint with Facebook and have a real business need already in your organization.  For the second response I find that the statement is usually not true.  In fact most of the people that I talk with that are working on "Facebook web parts" are really just modifying the MySite templates and pages.  When they explain to other people what they are working on they tell them they are working on "Facebook like" work.

When you are talking to customers, ISVs, or other developers and they say they are working on Facebook like web parts, make sure and ask if they are actually doing integration to Facebook or if they are building web parts that take advantage of the SharePoint User Profile.

Here are the current web parts that are completed for Integration to Facebook

1. ReceiverFacebookPart
2. UserProfileFacebookPart
3. FriendsFacebookPart

A few months back Matt Ranlett and I went to an event called "Sleepless" The Ultimate Office Dev Weekend.  At the event people were broken down into teams which worked over night to create an application for SharePoint.  Luckily Matt and I were both on the same team and I wanted to share with you what we created for SharePoint 2007 in one night.

We tried to create a site that looked and functioned similar to Facebook with the Social Networking features.  Although I have not finished all of the web parts or the site template, it is great to see what you can complete in less than 8 hours with no sleep.

List of functionality created:

• User Profile Picture Web Part
• Friends List
• Custom View of Friends List
• Enhanced Change Log information
• Image Gallery
• Custom Fields in the User Profile
• Custom User Profile Fields Web Part
• Mini-Feed Web Part
• Custom Display of Users Changes
• Discussion Board
• Calendar

I am sure we could have added much more, but we just ran out of time and we were honestly too tired.  Give us another 8 hours and you might be amazed what we could get done.

Recently there was a blog post that triggered a blog post, that triggered comments on the blog post.  The gist of the comment that shocked me is below referring to SharePoint.

"There's no place to do that today and file-centric systems can never bolt on enough little wikis and widgets to ever get there."

File-centric?  File-centric?  I really don't understand where this is coming from.  I could understand if someone was using SharePoint 2001 how they might think that it was a tool more for just files, but come on have you even tried or looked at SharePoint 2007?  I might even be able to understand if you called SharePoint 2007 list-centric.  As a framework to build many types of applications, the control is in your hands for whatever you want to create.  If you want to create or even extend the blog functionality that is available out of the box, you can.  If you want to extend the wiki pages, you can do that with ease.  If you want to build your own social computing application, the framework is built and readily available for you as soon as you are ready to build what you want.  It seems that many people really want the framework to have all of the capabilities of every application.  The tough part is that they want the applications ready for them without having to install add-on's or make any changes.  SharePoint has key areas that are part of the framework, but if you are missing something all it takes to add it is knowledge of .NET and Visual Studio.

It seems like the point should be to talk about how SharePoint can enable your business to succeed at initiatives within your organization, not to talk about buzz words or how product A only performs a certain set of functions.  Don't get me wrong, I really like a number of other applications and can learn a lot from them, but you need a platform for your Enterprise that can scale and meet many diverse needs.  It is just difficult to recommend a product that is either not extensible or does not provide a framework to build upon.  By having a framework to build upon, an application allows you to build on the pieces you feel are missing before the next official release of a product that might include those capabilities.  How would you feel if your IT department was installing new versions of an Enterprise application every other week.  You would always have a system in an uncertain state that could be unstable.  I would hate to have to support applications that were too agile and did not have enough time to be tested before they were moved into production.  That is why having a foundation for your applications with a deployment process that will let you add functionality without having to install applications from scratch can be useful.

At the end of the day, the social space has actually become so large with so many applications, users, and directions that it is many things to many people.  The same is true with SharePoint 2007, as it is large but still allows people to use it the way they want to use it.  SharePoint is many things to many people and it does not fit into one application definition.  This can make it difficult to explain to executives what it will do for their Enterprise because it could do many things for them.  Moving forward, as features become important to the community, you can add exciting and bleeding edge applications to SharePoint or ask Microsoft to make them available as part of this framework to build on and not just as an application that doesn't cross service boundaries.  Of course you might not get everything you ask, but it shouldn't stop you from asking. So keep making SharePoint what you want it to be.

One feature that I like in current release of the CKS:EWE (Enhanced Wiki Edition) is the ability to have custom tokens.

CKS:EWE Custom Token List

If you have installed the CKS Wiki solution you have probably seen the set of custom tokens that you can use on your Wiki pages that looks like this.

If you looked closely at the actual markup you might have seen two tokens that don't match the list.

They are:

• ''' '''
• --footer--

One feature that was added the EWE was the ability to create you own tokens.  Most people don't know that you can add your own custom tokens just by adding items to a SharePoint list.  To do that you will need to create a list with a specified name as well as have the correct fields in the list.

Step1: Create a list with the following naming schema

<listname>_WikiMarkup

Step2: Make sure the list has the following fields.  I am uploading a list template that you can use to create your list.  This list is courtesy of David Mann, make sure and thank him. =)

Step3: Add your own custom tokens that will display on the page.

Step4: Use the tokens in your CKS Wiki Pages.

CKS:EWE Custom Token List

I was talking to my friends, Andrew Connell and David Mann, about three of the most common Forms Based Authentication (FBA) options with SharePoint 2007 which he suggested I post for everyone to enjoy.

The three most common options are LiveID, SQL DB with management pages, and using a custom provider that stores users and roles in a SharePoint list.  Here are some suggestions I have for different options you have.

Windows Live Authentication Membership Provider
Provider Download: Windows Live Authentication 1.0

If you want a site that uses non-Windows based authenticated users I would recommend using the Windows Live integration. This allows you to authenticate users with their LiveID accounts and takes the burden of management off of you.  It isn't that difficult to set up but it will take a little bit of time the first time.

ASP.NET SQL Server Membership Provider
Provider Download: CKS:IEE (Internet/Extranet Edition)

If you want to manage and own the backend outside of SharePoint I would use SQL Server.  If you are using a sql backend I would probably suggest using the CKS:IEE FBAManagement solution.  Stacy Draper started a project on Codeplex, which he then helped integrate into the CKS:IEE project.  If you are using FBA with SQL I would recommend using the CKS:IEE.

SharePoint List Membership Provider
Provider Download: SharePoint 2007 List Membership Provider

Finally if you want to manage the user store and keep everything in SharePoint for a simple and single point of access  I would use a SharePoint list.  As for using a SharePoint List for authentication, my best friend Matt Ranlett who also co-authored the SharePoint 2007 Pro book has already uploaded it on codeplex if you want to use it.  There will be updates to this project in the near future from what I hear, but it should get you started.

 Update: If you want to create your own Membership Provider David Mann has the API version covered in his blog: http://www.mannsoftware.com/Blog/?p=89

I also have some providers listed on the site http://www.sharepointfba.com/ so feel free to take a look.  If you know of any other providers let me know and I will put them on the site. 

Adoption of any initiative in an orginazation, whether it be Web 2.0 applications or not, is critical to the success of the deployed application.  Successful adoption of the new applications is also vital to the person who is the sponsor or stake holder of the project.

Many times with Enterprise 2.0 you must rely on good planning as well as a little luck.  The most difficult part about Web 2.0 is being able to justify an ROI (Return On Investment) early on in a project.  I recommend you never make promises on social computing applications in your Enterprise because they can be very fickle to "control". By "control" I mean that they can be diffiult to get people to use them the way you intended, or the way you want them to.  

Part of the secret of the success of Web 2.0 is that the end users figure out how to best use an application the way they like and are able to collaborate in their own way.  Another part of the secret is to allow your users the flexibility to modify, change, or enhance the application to meet their needs, on their schedule.  If you are an executive and you just read that, I am sure you are feeling uneasy about trusting me now.  But trust me, this is one way you can make it work.  The great part about these social applications is that there isn't an exact way to make them work, but rather 100 ways for users to succeed in their goals. 

Here are some items that I will cover in the future that will help you succeed with the adoption of your social computing or Web 2.0 applications:

1. A good Collaboration Strategy
2. Clear goals on what constitutes success (this might be part of your strategy)
3. Social Computing company leaders
4. Fairly quick response time for applications
5. Reasons to have collaborative applications

Although you may have success in the absence of some of the items listed above, it will be a lot easier if you have these items in place.