An ex-colleague of mine used to call his SQL script generator "Super-Scriptmatic 2000". It impressed our then boss little, but was fun to say and use. We called every batch job and script "something 2000" from that day on. I'm tempted to call this one Menu-Matic 2000, except it's waaaay past 2000. Oh well. The problem: I'm developing a bunch of stuff in MVC. There's no PM to generate mounds of requirements and there's no Ux Architect to create wireframe. During development, things change. Specifically, actions get renamed, moved from
controller x to y etc. Well, as the site grows, it becomes a major pain to keep a static menu up to date, because the links change. The HtmlHelper doesn't live up to it's name and provides little help. How do I keep this growing list of pesky little forgotten actions reigned in? The general plan is: Decorate every
action you want as a menu item with a custom attribute Reflect out all menu items into a structure at load time Render the menu using as CSS friendly <ul><li> HTML. The MvcMenuItemAttribute decorates an
action, designating it to be included as a menu item: [AttributeUsage(AttributeTargets.Method, AllowMultiple = true)]
public class MvcMenuItemAttribute : Attribute
{
public string MenuText { get; set; }
public int Order { get; set; }
public string ParentLink { get; set; }
internal string
Controller { get; set; }
internal string
Action { get; set; }
#region ctor
public MvcMenuItemAttribute(string menuText) : this(menuText, 0) { }
public MvcMenuItemAttribute(string menuText, int order)
{
MenuText = menuText;
Order = order;
}
internal string Link { get { return string.Format("/{0}/{1}",
Controller, this.Action); } }
internal MvcMenuItemAttribute ParentItem { get; set; }
#endregion
}
The MenuText allows overriding the text displayed on the menu. The Order allows the items to be ordered. The ParentLink allows you to make this item a child of another menu item. An example
action could then be decorated thusly: [MvcMenuItem("Tracks", Order = 20, ParentLink = "/Session/Index")] . All pretty straightforward methinks.
The challenge with menu hierarchy becomes fairly apparent when you try to render a menu and highlight the "current" item or render a breadcrumb control. Both encounter an ambiguity if you allow a data source to have more than one menu item with the same URL link. The issue is that there is no great way to tell which link a person click. Using referring URL will fail if a user bookmarked the page. Using some extra query string to disambiguate duplicate URLs essentially changes the links, and also ads a chance of collision with other query parameters. Besides, that smells. The stock ASP.Net sitemap provider simply disallows duplicate URLS. I decided not to, and simply pick the first one encountered as the "current". Although it doesn't solve the issue completely – one might say they wanted the second of the 2 links to be "current"- it allows one to include a link twice (home->deals and products->deals etc), and the logic of deciding "current" is easy enough to explain to the customer.
Now that we got that out of the way, let's build the menu data structure:
public static List<MvcMenuItemAttribute> ListMenuItems(Assembly assembly)
{
var result = new List<MvcMenuItemAttribute>();
foreach (var type in assembly.GetTypes())
{
if (!type.IsSubclassOf(typeof(Controller)))
{
continue;
}
foreach (var method in type.GetMethods())
{
var items = method.GetCustomAttributes(typeof(MvcMenuItemAttribute), false) as MvcMenuItemAttribute[];
if (items == null)
{
continue;
}
foreach (var item in items)
{
if (String.IsNullOrEmpty(item.Controller))
{
item.
Controller = type.Name.Substring(0, type.Name.Length - "
Controller".Length);
}
if (String.IsNullOrEmpty(item.Action))
{
item.
Action = method.Name;
}
result.Add(item);
}
}
}
return result.OrderBy(i => i.Order).ToList();
}
Using reflection, the ListMenuItems method takes an assembly (you will hand it your MVC web assembly) and generates a list of menu items. It digs up all the types, and for each one that is an MVC
Controller, digs up the methods. Methods decorated with the MvcMenuItemAttribute get plucked and added to the output list. Again, pretty simple. To make the structure hierarchical, a LINQ expression matches up all the items to their parent:
public static void RegisterMenuItems(List<MvcMenuItemAttribute> items)
{
_MenuItems = items;
_MenuItems.ForEach(i => i.ParentItem =
items.FirstOrDefault(p =>
String.Equals(p.Link, i.ParentLink, StringComparison.InvariantCultureIgnoreCase)));
}
The _MenuItems is simply an internal list to keep things around for later rendering. Finally, to package the menu building for easy consumption:
public static void RegisterMenuItems(Type mvcApplicationType)
{
RegisterMenuItems(ListMenuItems(Assembly.GetAssembly(mvcApplicationType)));
}
To bring this puppy home, a call in Global.asax.cs Application_Start() registers the menu. Notice the ugliness of reflection is tucked away from the innocent developer. All they have to do is call the RegisterMenuItems() and pass in the type of the application. When you use the new project template, global.asax declares a class public class MvcApplication : HttpApplication and that is why the Register call passes in that type.
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
RegisterRoutes(RouteTable.Routes);
MvcMenu.RegisterMenuItems(typeof(MvcApplication));
}
What else is left to do? Oh, right, render!
public static void ShowMenu(this TextWriter output)
{
var writer = new HtmlTextWriter(output);
renderHierarchy(writer, _MenuItems, null);
}
public static void ShowBreadCrumb(this TextWriter output, Uri currentUri)
{
var writer = new HtmlTextWriter(output);
string currentLink = "/" + currentUri.GetComponents(UriComponents.Path, UriFormat.Unescaped);
var menuItem = _MenuItems.FirstOrDefault(m => m.Link.Equals(currentLink, StringComparison.CurrentCultureIgnoreCase));
if (menuItem != null)
{
renderBreadCrumb(writer, _MenuItems, menuItem);
}
}
private static void renderBreadCrumb(HtmlTextWriter writer, List<MvcMenuItemAttribute> menuItems, MvcMenuItemAttribute current)
{
if (current == null)
{
return;
}
var parent = current.ParentItem;
renderBreadCrumb(writer, menuItems, parent);
writer.Write(current.MenuText);
writer.Write(" / ");
}
static void renderHierarchy(HtmlTextWriter writer, List<MvcMenuItemAttribute> hierarchy, MvcMenuItemAttribute root)
{
if (!hierarchy.Any(i => i.ParentItem == root)) return;
writer.RenderBeginTag(HtmlTextWriterTag.Ul);
foreach (var current in hierarchy.Where(element => element.ParentItem == root).OrderBy(i => i.Order))
{
if (ItemFilter == null || ItemFilter(current))
{
writer.RenderBeginTag(HtmlTextWriterTag.Li);
writer.AddAttribute(HtmlTextWriterAttribute.Href, current.Link);
writer.AddAttribute(HtmlTextWriterAttribute.Alt, current.MenuText);
writer.RenderBeginTag(HtmlTextWriterTag.A);
writer.WriteEncodedText(current.MenuText);
writer.RenderEndTag(); // link
renderHierarchy(writer, hierarchy, current);
writer.RenderEndTag(); // li
}
}
writer.RenderEndTag(); // ul
}
The ShowMenu method renders the menu out to the provided TextWriter. In previous posts I've discussed my partiality to using well debugged, time test HtmlTextWriter to render HTML rather than writing out angled brackets by hand. In addition, writing out using the actual writer on the actual stream rather than generating string and byte intermediaries (yes, StringBuilder being no exception) disturbs me.
To carry out the rendering of an hierarchical menu, the recursive renderHierarchy() is used. You may notice that an ItemFilter is called before rendering each item. I figured that at some point one might want to exclude certain items from the menu based on security role or context or something. That delegate is the hook for such future feature.
To carry out rendering of a breadcrumb recursion is used again, this time simply to unwind the parent hierarchy from the leaf node, then rendering on the return from the recursion rather than as we go along deeper. I guess I was stuck in LISP that day.. recursion is fun though.
Now all that is left is some usage! Open your Site.Master or wherever you'd like to place a menu or breadcrumb, and plant one of these calls:
<% MvcMenu.ShowBreadCrumb(this.Writer, Request.Url); %> to show a breadcrumb trail (notice lack of "=" after <% and the semicolon).
<% MvcMenu.ShowMenu(Writer); %> to show the menu.
As mentioned before, the HTML output is nested <UL> <LI> tags, which should make it easy to style using abundant CSS to produce anything from static horizontal or vertical to dynamic drop-downs.
This has been quite a fun little implementation and I was pleased that the code size remained low. The main crux was figuring out how to pass parent information from the attribute to the hierarchy builder because attributes have restricted parameter types. Once I settled on that implementation, the rest falls into place quite easily.
