How to implement complex Menus/Breadcrumbs/Navigation structure in a SharePoint environment?

It is natural to try to use out-of-box components such as navigation providers, site map data sources and menu controls. However, it is very often  true for a complex content management SharePoint project that the out-of-box features are not enough. There are typically two reasons

1.       The logical structure is different from what out-of-box could envisioned or

2.       The custom CSS/JSScript involved is just too complex to be expressed in configuration parameter on out-of-box menu controls.

Notice, typically SharePoint developers do not have control on those factors since, for a complex project, web designs typically come from third party companies specialized in web design.

The solution, which proves to be successfully in several projects, is to use a XML file to define the site structure and use DataFormWebPart (Data View Web Part) to generate the HTML/CSS/Java script for the menus and even breadcrumb.

In the XML file (Site Map), each node may have an attribute for the URL to the page and some other Meta data attributes to help generate menus. For example, if a node should be only visible for certain groups of user, you can add an attribute to the node to specify the groups. Adding Meta data in the XML file is an extensible approach since you can add a new attribute easily. It is also a maintainable approach due to its centralized nature. Adding Meta data in publishing page content type is an alternative. However, it is decentralized and typically difficult to maintain.

With the XML file defining the complex logic structure, all you need to do is to convert it to HTML/CSS/JavaScript. Then, both problems mentioned earlier are solved. XSLT is the perfect candidate for this convertion and therefore DataFormWebPart can be used. In a publishing web site, you can simply put the XML file in style library and use DataFormWebPart to get its content. To this end,  a solid understanding of DataFormWebPart is a necessary. This is not a DataFormWebPart tutorial. Here are a few concepts you can use to quiz how well you understand DataViewWebPart.

1.       How to define a SPDataSource to query data from a list by Name.

2.       SPDataSource supports two modes of Query. Which are they?

3.       How to define an aggregate data source.

4.       How to use PostBack parameter binding.

5.       How to use a control parameter binding.

6.       How to reuse XSLT in two fashions, utility and framework.

If answers are “yes” to all of them and you also have good SharePoint designer experience, you are definitely ready to consider DataFromWebPart as an important part of your SharePoint site architecture.

Notice, item 6, “how to reuse XSLT in two fashions”, is crucial if your XSLT code exceeds a few hundred lines. With DataFormWebPart, you can use XSLT “import” to reuse the templates/variables from other XSLT files. (I have seen some blog saying it is not possible, which is not correct.). You can achieve “FrameWork” like reuse based on the following feature of XSLT:

A template will override the ones with the same name but defined before it. For example, you can have a XSLT file “FA” defined a template “TA”, which invokes template “TB”. You can provide a default implementation for “TB” in “FA”. Another XSLT file “FB” can import “FA” and provide a different implementation of “TB”.

“Framework” style reuse is very powerful. It is just like the “virtual” function in object oriented programming.