To complete my navigation controls toolbox, I needed two other types of controls; global navigation and footer.  When building the other types of navigation controls - side navigation and breadcrumbs - the content was accessible and could be iterated easily by using a foreach loop because of their location in the same channel.  For global and footer navigation, sometimes this is not the case.  Some other approaches I have used to solve this problem in the past include:

• Creating a channel called _footer and _global that is excluded from the regular navigation in published mode.  The problem with this approach is that the results show up in the URL if the user selects an item in this channel.
• Ensure that the information architecture accounts for the footer content in the root and can be easily pulled using a custom property (something like “DisplayInFooter = True” or “DisplayInGlobalNav=True”).  Problems include too many items in the navigation, or content contributors selecting the wrong items to be displayed.  This also presents problems when you are using multiple channels and/or large content stores since a custom property search is across the entire repository and cannot be scoped initially.
• Create an admin posting that contains a list of links and text to display.  This approach creates a training issue since the content contributors need to know the structure of the site.  The template also has to be modified in order to add a new link item.

You may have used some of these approaches or even some not mentioned here.  The fundamental truth of this type of navigation is that it doesn’t change often and content contributors should not be allowed to alter the structure of the site.  If business users need that much flexibility, then maybe one the aforementioned approaches’ is feasible for your site.  If not, then the technique detailed in this post may be useful.

By adding this new technique to my MCMS development tool box, I can quickly build MCMS managed sites that have a lot of flexibility and are less fragile to change, especially in the UI.  By separating the presentation from the code-behind, I can quickly skin my site with minimal to no impact to the code base.