An easily navigable web site is half of the battle. I wouldn’t write about the revolutionary navigation designs and ideas here, let the web designers struggle with that. In this post, only cool and standard developer navigation will be considered. So let’s begin!
Our syllabus states the following on this objective: when to extend site map provider, treeview menu vs. site map path, programmatically manipulating site map nodes, overriding menu rendering by controls adapters, filtering site map nodes based on user roles. A nice collection.
The foundation of ASP.NET site navigation is the SiteMap. Now there are some classes with this name, so let’s lay out a terminology. The SiteMap is the XML document from where the data originates. It populates the SiteMapDataSource data source object, which looks for the web.sitemap file to get its data. It also populates the SiteMapPath control, which is a graphical representation of the sitemap, and is also known as breadcrumbs. I never understand why do they call it that way, but I have no English background.
So what’s the big deal with the epic battle between SiteMapPath and TreeView? The secret is that TreeView actually uses the SiteMapDataSource control to gain its data, so it reflects any changes made in the SiteMapDataSource. However, SiteMapPath queries the underlying web.sitemap file, without the intervention of a datasource object, so changes made in the SiteMapDataSource won’t affect it.
A little info about web.sitemap: it must be placed in the root directory, must have a root element, but you can define sub sitemaps inside elements. So the following XML is valid: