Yet Another SDL Tridion Navigational Approach

If you've done Tridion implementations long enough, you'll recognize the three classic navigation approaches.

The Basics

• Pages and Prefixes. Pages in a Structure Group with a prefix naming convention (e.g. 010 Summary, 020 Detail Page) could create your navigational relationship. This is typical for global navigation and can be published in a single file (e.g. .xml or .sitemap) for server-side rendering. This has been mentioned on StackOverflow and discussed/debated about here, here, here, and here.
• Link Lists. A container component links to other components. Simple and ultimate flexibility with some extra work for authors.
• Taxonomy. Categories and Keywords create a relationship that presentation-side code could query or otherwise "transform." Chris Summers presented on this in a community webinar.

But Now...

Let's add one more to the list:

• In-Page Navigation via Component Presentations!

Pardon the enthusiasm, this isn't really new. Your Page Template logic can trivially group or add navigational elements on the same page. For example you could create tabs or in-page bookmark links for a simple, automatic and easy-to-maintain approach.

Basically:

• With a little CSS and JavaScript (e.g. JQuery) we get Navigation via Markup.
• Which means a template change. See example markup for some JQuery tabs.
• Which means Component Presentations can drive in-page navigation schemes.

Now slowly put down that Link List, especially if you need auto-generated, in-page navigation for a small set of manually curated CPs. You might choose another approach for something that feels like a library or catalog, or if you need more organization than a simple list.

In the example above, you may need to make some choices on how a Detail page would reference the CPs on the Index Page. You can bake and/or fry the relationships.

Bake or Fried?

I've heard "baked" refer to Content Manager-side rendering for awhile, but I first heard "fried" as a term for CD-side logic from Elena Serghie. When dealing with Navigation, you'll want to consider which parts are baked in and which you're willing to fry.*

Bake. You will typically take a "snap-shot" of existing relationships and bake part of your navigation using template logic. This would be TOM.NET in C# Assembly Template Building Blocks (or fragments) along with some HTML and DWT syntax in layout TBBs (or CM-side XSLT). The trade-off with baking is improved presentation-side performance in exchange for additional template rendering time. Fully baked assumes the CM-side snap-shot is accurate, whether or not certain items are published (see half-baked for a good compromise).

Fry. The Content Delivery API lets you "fry" up whatever you'd like based on relationships and custom metadata. In the Tridion.ContentDelivery.Meta namespace, you could instantiate a PageMetaFactory object, get a page's meta, then retrieve appropriate Component Presentations and their Component and Template IDs (thanks, Mihai, for the tip). Up to you on what to do with either the references or rendered content next.

Half-baked. Ideally you would at least use dynamic linking to make sure links resolve correctly even if most of it is baked CM-side.

In the side nav example above, you could:

• Bake the links via page template code that retrieves the CPs from the Index page. Create the relationship between the two via a link, by naming convention/location, or some page metadata.
• Fry the links by using pageMetaFactory.getMeta to get the CPs in CD-side code. Create the relationship between the two in the same way by link, convention, or metadata.

*I've been told Tridionaut Q's used the term "Fry" years back. But what do we call Event System automation? Microwaved? And maybe Core Service retrieval could be steamed? #metaphorstakentoofar

Got you thinking yet? Join The Tridion Navigation debate on TridionDeveloper or leave a comment below.

I licensed the "Yet Another" phrase from Yet Another consultant himself, Mihai Cadariu for only two beers.