Here’s a really, really esoteric CMS implementation tip: abstract your crumbtrails.
What I mean is to make sure your crumbtrails can be generated from something other than the content in the CMS. I’ve finally learned this for good.
I’m in a middle of an EPiServer implementation now. EPiServer has a strong content tree, so I wrote a quick control to iterate through a page’s ancestors and form up a crumbtrail. This is great…until you get one of these situations:
- You have a page not in the content structure of the CMS. Some page that sits outside the CMS. In any project of appreciable size, you will have these.
- You have a page that maps to a single content item, but has different logical states which require different crumbtrail navigation. Based on certain criteria, the page might have more than one state, but insofar as the CMS is concerned, it’s the same content object, so the crumbtrail is the same.
You need to have an abstraction layer for crumbtrails. You should have some method for “AddCrumbtrailSegment” which takes a title and a URL. Then, if you have a page outside the CMS, you can form a crumbtrail from scratch, or, with a single call, you can add a segment to an existing crumbtrail.
If you’re working with a page that’s solidly in the CMS, feel free to use the CMS structure to form up the crumbtrail, but use your abstraction layer to do it. In the end, forming the crumbtrail from the CMS structure should be one way to do it, not the only way to do it.
This tip probably holds true for any navigation element in the outer layout of a CMS template – general navigation, footer items, overhead static menu items, etc.
Told you it was esoteric.