We want to provide a standardized site map across our SharePoint publishing enterprise. We are using SharePoint to provide a content management solution for our partners, and migrating from Microsoft Content Management Server 2002. Part of the planning is defining the set of web parts that we will enable for our partners to use in creating their own sites and pages. Our partner count is in the hundreds at this point so we have a wide range of abilities to acommodate. Some of the users are web design and SharePoint gurus, and some of them have no HTML experience. It is for the latter that we need to be especially conscious.
TableOfContentsWebPart
Our first attempt was to use the out-of-the-box TableOfContentsWebPartThis a useful part because of its customizability, but the same thing that makes it useful also makes it quite complexIt doesn’t provide a nice nested <ul> rendering out of the box, and we don’t expect a majority of our users to have SPD or any XSL expertise which are both needed to make this thing to what you wantSo we sought to customize the part to render a nested <ul> tree with some custom XSL and then export the customized webpart to the gallery.
When I started on the XSL template, I planned on using a recursive template because I had expected the XML coming from the TOC to be hierarchical (like the data it represents), something like:
<site>
<web>
<page title="a page" url="/pages/default.aspx"/>
</web>
</site>
Unfortunately, the XML is one level and uses a level attribute on the items (level="1", level="2") to be used for transformingNot pretty, but it doesn’t matter right? I could still approach this with a fairly simple recursive XSL template. Afterwards, we had a perfectly good site map that could be exported and reused by anyone. Even more unfortunately though, the TableOfContentsWebPart has a limit on the number of levels it will emit in XML. The limit was 3. When the team came to me and said, "Hey we need this to show more than 3 levels," my first instinct was to think that there must be a good reason for limitingObviously, you can’t let this thing run infinitely deep, but why 3 levels? I surmised that 3 levels was probably enough to handle most sites and that if you have more than 3 levels of structure, using a site map wasn’t going to benefit a userIf at every level you have only 3 items, your tree starts getting big fast… level 4 has 81 items, level 5 has 243 items, level 6 has 729 items! Yeah that’s a good argument to not go past 3 levelsPerformance aside, who is going to spend time reading through a lot of items in tree format to find a page or site? Isn’t that why we have an awesome search bar on every page? Well, usability and performance are not always of concern to our partners, some of which actually do have sites with structure up to 7 levels deep.
PortalSiteMapDataSource
My solution was to write a simple web part using the PortalSiteMapDataSourceThis object was meant to do exactly what we are trying to do and is also built for performanceRead Chris Richard’s blog entry, Increased performance for MOSS apps using the PortalSiteMapProvider, from the Microsoft Enterprise Content Management teamIt will provide speedy access the the underlying navigation tree and will handle caching for meAs Chris says, the first call to this provider won’t be as fast as using the OM yourself, because it’s handling a lot of caching heavy lifting in the background, but it will improve the performance of your Site Map overall and provide for very little coding.
So a couple hours later and some frustrating SharePoint development, we have a standard site map web part in our galleryAll our users have to do is add the web part to a page and if they want to, write some custom CSS to style it out.
CodeProject
