Today I’ll be reviewing the SharePoint SDK’s. I’m not saying they are bad, but I’ve never found any good overview about ‘em. And I guess such an overview can be usefull, especially for people starting with SharePoint.

Before we begin, let me explain what a SDK is. A SDK is a Software Development Kit. It’s a set of resources designed to help understanding a specific technology. Sometimes a SDK is necessary to allow development with such a technology. (I’m thinking about the Java SDK) So, what are those resources? Well, it depends. They can include a lot of things. But most of the time, you’ll find documentation (CHM’s and the likes), samples, tools, templates, … you name it. Really usefull stuff.

SharePoint SDK’s come in different flavours. There is the online MSDN section with all the documentation, together with links to seperate downloadable resources. Or you can directly download the SDK. This download will include the documentation, samples, etc, but is suited for offline use, as an internet connection is not required once installed.

So what are the SharePoint SDK’s? First off, there is the Windows SharePoint Services 3.0 SDK. This SDK will only cover WSS related topics. And although it’s quite usefull, the offline installer includes only a couple of files, more specifically: the actual WSS 3.0 reference and a compilation of technical articles. Both can also be found on the online version.
The Microsoft Office SharePoint Server 2007 SDK is much more interesting. It includes both WSS files, and adds much more reference on the MOSS-only technologies. Also, it features some nice samples with source code. This gives us the opportunity to catch a glimpse at how the guys at Microsoft are using SharePoint, which is quite nice if you’re starting off with SharePoint and have no idea how to begin development. The MOSS 2007 SDK also includes the Enterprise Content Management Start Kit (ECM Starter Kit). This starter kit gives some in-depth information on the new ECM features and platform in Office SharePoint Server 2007. Moreover the starter kit is the collection of some white papers and code samples.

Next is a handy overview for the SDK’s:

In short, the MOSS SDK completely covers the WSS SDK. And even if you don’t have MOSS, the MOSS SDK is still very interesting and worth the download, as the samples give a great in-depth look at coding for SharePoint. ’till next time!

Navigation can break or make your site, and more specifically, your site’s usability. One of the tools to achieve a good navigation experience is the breadcrumb. In opposite to a menu structure a breadcrumb is quite space saving. And this is, according to MSDN, because it displays a hierarchical path of hyperlinked page names that provides an escape up the hierarchy of pages from the current location.

Basicily, it shows the current node and all its parent nodes. For the sake of completeness, it’s also called an eyebrow. And I’m not making this stuff up.. :p All in all, I’m pretty sure you guys all know the beast. I, for one, find it pretty usefull… as long as it keeps consistency along the way.

Back to SharePoint now. A breadcrumb within ASP.NET is called a SiteMapPath. This is a control which uses an XML sitemap of your site structure to keep track of your every move. It then shows your progress in a nice little breadcrumb. To access the sitemap, we need to use a .NET object called SiteMapProvider. As this is an object in code, we can change the way such a SiteMapProvider works and feed him some custom links programmically in stead of using a XML scheme. This gives a whole lot of flexibility. And because of SharePoint’s inherent dynamic nature, this is why almost all SiteMapProviders within SharePoint are implemented this way.

WSS natively offers a couple of SiteMapProviders (SPNavigationProvider, SPSiteMapProvider, SPContentMapProvider and SPXmlContentMapProvider), each with its specific use within your site. MOSS adds about 10 more. And it’s in MOSS, the troubles begin. Say, you design your site and you have to choose the breadcrumb’s location. Done? Ok.. which SiteMapProvider will you use? The default.masterpage has two (event up to three) breadcrumbs integrated in its design, all with different SiteMapProviders. (I wonder why this design decision was made) The two providers used are:

• SPContentMapProvider: the default WSS SiteMapProvider which shows nicely all different items and lists
• CurrentNavSiteMapProviderNoEncode: a provider which parses pages, not as items in a Pages list, but as sections within the site, which is pretty clean.

My requirement was: I want both advantages: items and lists nicely shown and pages cleanly parsed. Unfortunately, the WSS SiteMapProvider does not know pages and the MOSS SiteMapProvider does not parse lists and items. So, I decided to develop my own SiteMapProvider.

A SiteMapProvider consists of two things. A class containing the logic and an entry in the web.config enabling the SiteMapProvider’s use in a masterpage. Let’s first start with the logic.
As this is a MOSS problem only, I created a class inheriting from a MOSS SiteMapProvider: CombinedNavSiteMapProvider. This one will show nice complete breadcrumbs, except of course for lists and items. The SiteMapPath control uses one particular property from the SiteMapProvider: CurrentNode. So this is the one to override. This is the code I came up with:

public override SiteMapNode CurrentNode
{
  get
  {
    SiteMapNode node = base.CurrentNode;
    SPListItem listItem = SPContext.Current.ListItem;
    string url = HttpContext.Current.Request.Url.AbsolutePath;
    bool isItemSelf = listItem != null && url.EndsWith(listItem.Url);
    if (!isItemSelf)
      node = SiteMap.Providers["SPContentMapProvider"].CurrentNode;
    return node;
  }
}

Two things to notice. I check if the url is a page by comparing the requested url with the current item’s url. If they both match, it’s a Page alright. Second thing, to parse with the default WSS provider, one can find the correct provider in the static property Providers from the type SiteMap.
The last piece of the puzzel is the entry in the web.config. This is pretty straight forward. Go to configuration.system.web.siteMap.providers and duplicate the entry of the provider you inherited from. Change the assembly details and you have yourself a working SiteMapProvider.

All in all, this was quite a challenging change to find a solution for and to implement it. But once up, it works like a charm and seems so easy. See you next time!

When searching in MOSS, your results are shown in the search center. This is a special site you can create within your MOSS site collection. When using the default master pages, everything looks nice. The search box is in some blue area, while results get listed on the page. So far, no problem.

Say you want to develop a new master page. You take your basic place holders and arrange them on your page, the way it best fits your design. One of those placeholders is called PlaceHolderTitleBreadcrumb. What does this place holder contain? You might have guessed it, it should contain the breadcrumb of the page. And this is very crucial. Master pages are a technology which rely on “design by contract“. This is a special way of designing based on trust. In our master page we add content place holders to enhold specific parts of page. We give them specific locations and identifiers and we expect the correct functionality in it. Sadly, this is not always the case.

The search center is one of those areas not respecting the content place holders. Let’s look what will happen, when changing the master page of our site. (And once again, I’m just switching to a MOSS master page)

As you can see, the layout of the pages is somewhat disturbed? Why? The page layouts, which are used in those pages, give another meaning to our PlaceHolderTitleBreadcrumb place holder. They have the complete search box logic in it. A valid question here would be: why? Well, my guess is: the search looks nice when used in the default master page. They wanted to distinguish the search box area from the results. So they added the search box in the PlaceHolderTitleBreadcrumb. Now, for people who have moved this place holder (to the top, for example) within their custom master page, this can be a serious problem.

The solution, per se, is not that complicated, nor hard to apply. You just open up the two page layouts (SearchMain.aspx and SearchResults.aspx in your site collection’s masterpage catalog) move the search boxes from the PlaceHolderTitleBreadcrumb to the PlaceHolderMain. And you’re done, quite simple. But this is not where the problem resides. What to do with your other search centers in your farm? … Let me think… How about altering the files directly on the disk in the 12 Hive? This way, when provisioning, the search centers will have a nice layout in all master pages? Ok, but what if your distributing the thing? Well, in this case, one could provide some altered page layouts to use, and dynamically switch the old ones to the new ones in a feature receiver. And so on, and so on…

I hope most of you will realize these practices are mere patching up work. They are not giving a real solution. Sadly, most of the times, this is what we have to do to get things done. The true solution consists of conventions, and keeping them applied. Unfortunately, in a team as big as the development team of Office, this can be quite cumbersome. Hopefully they’ll keep that in mind for next iterations, and try to be more consistent. Until next time!