Part 1 – Tables, Unordered Lists, and SharePoint
Part 2 – Custom Control Rendering
Part 3 – Hooking it all up with jQuery

Since the out-of-the-box SharePoint menu control renders the HTML in <TABLE> elements,skinning and customizations are limited.  The rendering for my MegaDropDown is based on the <DIV> and <UL> elements and provides many more customization options.  Note:  In SharePoint 2010, the AspMenu control has an option to render with <UL> based elements.  I haven’t ported the MegaDropDown to SP2010 yet, but will post my results when I get a chance to convert it.

Once you bind to the navigation’s data source, you can easily walk through the collection of items and render HTML on the fly. I was doing this in my first iteration of the MDD, but things got a little complicated as I needed to parse all the available menu options, and then apply some custom jQuery logic once I had everything calculated.  That said, I opted for a two pass approach:

Pass 1 – Iterate through the navigation data source and build my own customized collection that stored some extended properties that were specific to the MDD.

Pass 2 – Iterate through the custom collection and render the HTML

While there is obviously an extra step involved (and another copy of the navigation), it really simplified the code and the overall process.

The custom collection essentially consists of several container classes that keep track of the navigation items (Title, Url, Type).  The first two properties are pretty obvious but Type is tailored for the MDD.  Type determines if the item is a standard menu item or is an image.  A benefit of the MDD is that is has the ability to display a site “image” within the navigation drop down itself (more on this later).

Displaying and grouping items

There are two formats for displaying menu items: standard and grouped.  Standard is just what you would expect and menu items are rendered in the order defined in SharePoint.  Grouped items however, allow you to organize links into categories which can significantly simplify the interface when needing to display dozens of links.  A major requirement of the MDD project was to keep the customization as transparent and compatible with SharePoint as possible.  The grouping logic is one place where some customizations are visible.  In order to group items there needs to be a way to define the group name (i.e. category) as well as the links are associated with each category. 

MegaDropDown with uncategorized items

MegaDropDown with categorized items

The client I was working with was very adamant about using the standard SharePoint "Modify Navigation” UI so I am not entirely happy with the solution for grouping, but it does solve the problem without building any new web forms or pages.  A special syntax was created so an admin simply has to enter it within the standard UI.  When you want to specify that a link should fall within a specific group, you append the link title with $GroupName.  For example, if you wanted to create a group named Offices and add the Chicago office, you would enter:

Chicago$Offices

That’s it.  The parsing code will detect this and separate out the names automatically.  Here’s how it would look in the Navigation Link dialog:

As I said, I don’t exactly like the approach, but it is a pretty low-impact solution and took about 20 minutes to write the parsing code—and no UI changes were needed!

I keep track of each MenuItem in a generic List.  Since there are two types of dropdowns (standard and grouped), I keep track of each link type in a separate List. 

Keeping track of all of the navigation types is a little tricky, so hopefully the following diagram helps illustrate how the collections relate:

Once all the parsing is done and I am ready to render the items, I simply iterate through each list and generate the HTML:   For brevity, I’ve removed some of the housekeeping logic, but the RenderMenus() method walks the main List<> and calls RenderGroupItems or RenderMenuItems() accordingly:

Rendering Menu Items

For the most part, displaying each of the menu items involves the same logic except you iterate through each of the top level items menus.  As you read each item, you just emit individual <li> elements that represent each of the menus.

The end result of the HTML might look something like this:

The code is fairly straightforward and I tried to make the HTML as simple as possible.  The entire navigation, including the mega drop down sits inside the main <div> container ‘navcontainer’.  The ‘navigation’ <UL> handles the horizontal top ‘tabbed’ navigation menu.  Since it is <UL> based, I style the layout and appearance with CSS.  Each <LI> represents a tab defined in SharePoint’s navigation page. 

When sub-navigation items exists (e.g. sub-sites), a new <DIV> (menu) is defines the drop down itself.   Although I tried to follow a flexible <DIV> based layout, the sub-items list is tabular and fits nicely in a <TABLE>.   If grouping exists, each group (or category) is displayed with a styled <H3>.  All the sub-items are then displayed with an embedded <UL> (sub-nav).

In my next and final article, I will explain how I hook it all up with jQuery.  (I promise that it won’t be nearly as long between postings).

As always, comment or email me if you have any questions.

Part 1 – Tables, Unordered Lists, and SharePoint
Part 2 – Custom Control Rendering
Part 3 – Hooking it all up with jQuery

Although the styling and navigation had to be scrubbed, a screen cast of the final solution can be found here:

Providing users with rich navigation is the latest trend in web design and the hottest technique today is the Mega Drop Down.  Rather than providing single column navigation, Mega Drop Downs present menu information in a rich, two-dimensional format:

As you can see in the above example, the drop down menu provides navigation links in multiple columns (and even has a slick transparency effect).  Sites with Mega Drop Downs are popping up all over the web and usability guru Jakob Nielsen has written a great article describing the benefits.

For most sites, implementing a Mega Drop Down is fairly straightforward and most of the effort focuses around CSS.  If you have ever customized navigation in SharePoint, you are well aware that things are easy enough—but only to a point.

Out-of-the-box, SharePoint uses the SharePoint:AspMenu class that inherits from the standard ASP.NET asp:Menu control.  This control provides the ability to be skinned and can be customized through the use of CSS and ItemTemplate support, but at its core, it still is a <TABLE> based control and isn’t flexible enough to radically change its appearance.

Rather than relying on <TABLE> based navigation, CSS unordered lists <UL> can easily be used to implement navigation.  I want to keep this post focused on SharePoint and not CSS, so if you want to read up on how to create the shell for the Mega Drop Down, I recommend starting with this article,   To summarize the concepts, we essentially create a nested set of unordered lists:

<ul id=’topNav’>
  <li>Employee Services</li>
    <div id='mdd'>
      <h3>Benefits</h3>
       <ul id='subNav'>
        <li>401(k) Information</li>
      </ul>
     </div>
   </li>
</ul>

The ‘topNav’ <ul> represents the top navigation that is displayed horizontally.  The <div> is the actual Mega Drop Down itself and contains one or more ‘subNav’ <ul> elements that represent the sub-menu items.  The <h3> tag is used as a category heading so we can group menu items together (more on that in part 2).

CSS is used to style the outer ‘topNav’ so elements are displayed inline.  We also hide the <div> as it should only appear when you hover over an <li> within ‘topNav’.  I applied some extra styling, but so far, navigation should look something like this:

We’ve defined the structure of the menu and navigation, but up until now, it has all been static.  To make this work in SharePoint, we have to provide a method of displaying navigation dynamically.  There are several different methods of replacing the default navigation, and for this solution, I opted to create a custom navigation control.   A great overview of the various options can be found here.  Earlier I mentioned that out of the box, SharePoint uses the asp:Menu control to render menu items.  This is a standard data-bound control that references a DataSource for rendering navigation.  If you look inside default.master with SharePoint Designer, you’ll see how all this works:

<SharePoint:AspMenu
  ID="TopNavigationMenu"
   DataSourceID="topSiteMap"
   runat="server"
   ...
/>
<asp:SiteMapDataSource
  ShowStartingNode="False"
   SiteMapProvider="SPNavigationProvider"
   id="topSiteMap"
   runat="server"
  StartingNodeUrl="sid:1002" />

The SiteMapDataSource is a standard ASP.NET data source control and is widely used in ASP.NET web development.  If you are not familiar with how navigation works in ASP.NET, MSDN has a great overview.  The important concept to note here is the SiteMapProvider property and the SPNavigationProvider value.  SPNavigationProvider is a class that follows the standard provider model and essentially is the code that retrieves the navigation hierarchy from SharePoint.  SPNavigationProvider handles all the mundane tasks of retrieving the data and security trimming results so users don’t see links to sites that they may not have access to.

As mentioned, we are scrapping the SharePoint:AspMenu control because it renders <TABLE> based navigation and are replacing it with a shiny, new <UL> based navigation control.  Other than being difficult to pronounce (and type), HierarchicalDataBoundControl is the underlying class that asp:Menu uses to retrieve its data.  We are simply bypassing asp:Menu and its bias for <TABLE> layouts and going directly at the data.   Our custom control’s declaration looks something like this

:

public class MegaDropDown : HierarchicalDataBoundControl
{
   protected override void PerformDataBinding()
   protected override void Render(HtmlTextWriter writer)
}

The two methods that we need to override are PerformDataBinding() and Render().

The PerformDataBinding method is where we will retrieve our data from the data source (indirectly through SPNavigationProvider) and then (ultimately) parse the hierarchical data that is returned.  Initially, the GetData() method is called to…wait for it…get the data.  In general, these controls can represent many different flavors of data.  Since we are working with hierarchical data, GetData() happily returns a reference to a HierarchicalDataSourceView object that represents a view into the navigation.  A data source view is similar to a database view and has the ability to provide a subset of data based on a query.  Coincidentally, HierarchicalDataSourceView points to a nested list of the navigation data.  For our purpose, there isn’t a need a need to filter results and a simple call to the Select() method will suffice.

Having a reference to the view is great, but what we really want is an enumerable reference to the actual data (remember, the view is just an abstraction of the data).  Having the IHierarchyData interface gives us so many options (well, not really) but since everyone likes enumerable objects, getting to the data is only a two-step process.  Once we call GetHierarchyData(), we only need to invoke IHierarchyData.GetChildren() to access the enumerable data

Surprisingly it is very straightforward and only involves a dozen or so lines of code::

protected override void PerformDataBinding()
{
   base.PerformDataBinding();

   // Do not attempt to bind data if there is no data source set.
   if (!IsBoundUsingDataSourceID && (DataSource == null))
      return;

   HierarchicalDataSourceView view = GetData("");

   if (view == null)
      throw new InvalidOperationException("Cannot get any data.");

   IHierarchicalEnumerable enumerable = view.Select();

   if (enumerable != null)
   {
      IHierarchyData data = enumerable.GetHierarchyData(rootItem);
      IHierarchicalEnumerable newEnum = data.GetChildren();
   }
}

Next up is the HTML rendering and actual control implementation…Part 2 – Custom Control Rendering