With this blog post I introduce several articles about navigation in Sharepoint. Here I would like to describe basic architecture of MOSS navigation. The understanding of these basics is required to customize navigation in Sharepoint.
Important point is that Sharepoint navigation is built on top of ASP.Net navigation. I.e. all that you know about ASP.Net navigation will help you in Sharepoint as well. As you know ASP.Net navigation architecture separates UI and navigation data. It is based on 3 main components:
- navigation UI controls which display navigation items. In Sharepoint most widely used navigation control is AspMenu control defined in OTB master pages of publishing sites. As said here:
The AspMenu class that ships with WSS 3.0 (and by extension MOSS 2007) is nearly identical in behavior to ASP.NET 2.0’s Menu class (as the name implies). AspMenu derives from Menu and adds tweaks to work around a few reasonably well known annoyances and provides improved highlighting support.
- navigation data source - intermediate abstraction layer between UI controls and navigation data returned by navigation providers. You can use ASP.Net SiteMapDataSource control or PortalSiteMapDataSource from MOSS API which inherits SiteMapDataSource. The main purpose of these controls – is to add additional configuration abilities for developers (e.g. specify starting node URL, starting offset, etc.) and bind to site map data and presents its view. I.e. SiteMapDataSource returns instance of SiteMapDataSourceView or SiteMapHierarchicalDataSourceView - it’s kind of “view model” for navigation;
- navigation providers which return navigation data (SiteMapNode instances). In Sharepoint navigation data is stored in content database, so navigation providers fetch navigation nodes from db – this is important point to note. SPSiteMapProvider, SPContentMapProvider, and SPNavigationProvider are part of the WSS classes; PortalSiteMapProvider is part of the MOSS object model.
Here is a figure from msdn which explains how these components are used in OTB master page of publishing site:
Three PortalSiteMapDataSource controls are embedded. Each maps to a definition for a provider within the web.config file of the site. The SiteMapDataSourceRoot control uses the CombinedNavSiteMapProvider control and is connected to the breadcrumb controls. As its name suggests, it combines the two other PortalSiteMapDataSource controls into one. The siteMapDataSource1 control provides the data for the top navigation bar, and the siteMapDS control provides the data for the vertical navigation control
In order to avoid terms mess I would like to notice that “top navigation bar” here is “global navigation” in terms of Sharepoint and “vertical navigation control” is “current navigation”.
So what happens when we change navigation in OTB “Site Navigation Settings” page of the Sharepoint site (Site Actions > Site Settings > Modify All Site Settings > Navigation)?
Sharepoint saves changes made on this page in content database. I.e. here you can affect only SiteMapNode instances returned by providers. All visual appearance settings are still available only from page which contains SiteMapDataSource and UI controls (master page). Notice that you can also change navigation settings programmatically using the following members of PublishingWeb class:
Gary Lapointe implemented 2 stsadm commands which can be used for changing navigation settings using stsadm utility: gl-setnavigationnodes and gl-copynavigation. Internally these commands use the mentioned above members of PublishingWeb class. Details can be found in his blog.
That’s what I wanted to write about basics of Sharepoint navigation. Hope it will help you to increase understanding of internal Sharepoint mechanisms. Based on this knowledge you can create you own custom navigation providers in MOSS. I’m going to write separate post about it.
Update 2010-03-14. Also you can use SPWeb.Navigation property which returns instance of SPNavigation class with the following public interface: