Avoid hard-coded TCM URI in Tridion-Related Code - tridion

Question

We often need specific items (schemas, templates, or components) in Tridion-related code. Template, Content Delivery, Workflow, or the Business Connector (Core Service) regularly need references to Tridion Content Manager URIs. We can link to components, but I typically see either hard-coded values or WebDAV URLs for everything else.
Hard-coded values
I understand hard-coding Tridion Content Manager (Native) URI's is a bad practice except for a few scenarios:
To simplify example code and make it clear what a variable is
When generated for use in Content Delivery (CD) API logic
Whenever possible we use the given API or WebDAV URLs to reference items, otherwise we must avoid using Content Porter on anything that references TCM URIs (or somehow make these references "configurable" outside of Tridion).
WebDAV URLs
WebDAV URLs seem to be better for a few reasons:
Hard-coded values in design template building blocks (TBBs) or other template formats remain intact with SDL Content Porter (breaking a relationship when moved through CMS environments, with an exception described below)
"Configuration" components that refer to specific items also do better with SDL Content Porter, though differently-named paths can "break" relationships
Use cases
In addition to having template that work well with Content Porter, I would like to localize folders and/or structure groups in lower publications. This can help with:
CMS authors that read different languages
translate item names and paths to appropriate languages
maybe help users navigate better (e.g. I suspect different-named folders may reduce confusion for where authors are in the BluePrint)
One Approach
To make references "Content Porter-friendly," at least for Template Building Blocks, I know we can use WebDAV Urls in components making sure to localize each path to the right locations in children publications. For example:
Code checks Publication Metadata
Publication Metadata points to a "config component"
Config component has paths as WebDAV URLs
As long as we set the Publication Metadata and localize the fields to the correct paths per publication, this will work for most scenarios.
Questions
Did I get this right? Is there a simpler or easier-to-maintain setup?
I believe we can alternatively use includes or map unmanaged URI in template code.
Anyone have an example of the #include approach? Do I use that at the top of a TBB and/or DWT and do references get replaced regardless of Template Mediator (e.g. will this work with XSLT Mediator, Razor Mediator, etc?)
Does the included reference work in lower publications or is this just for Content Porter? In other words, if I reference "tcm:5-123" will the template correctly reference "tcm:17-123" in publication 17?

Answer 1

I tend to follow a few simple rules...
There is no single valid reason to ever use a TCM ID in anything - template code, configuration components, configuration files.
If I need webdav URLs in configuration, I try to always make them "relative", usually starting at "/Building%20Blocks" instead of the publication name. At runtime I can use Publication.WebDavUrl or PublicationData.LocationInfo.WebDavUrl to get the rest of the URL
Tridion knows what to do with managed links, so as much as possible, use them. (managed links are the xlink:href stuff you see a bit all over Tridion XML).
I also tend to use a "configuration page" for content delivery, with a template that outputs the TCM IDs I may need to "know" from the content delivery application. This is then either loaded at run time as a set of configuration variables or as dictionary or as a set of constants (I guess it depends how I'm feeling that day).

Answer 2

Although we commonly refer to a Template Type implementation as a Template Mediator, that's not the whole story. A Template Type implementation consists of both a Template Mediator, and a Template Content Handler, although the latter is optional. Whether a given implementation will process "includes" correctly depends not on the mediator but the handler.
A good starting point in the documention can be found by searching for AbstractTemplateContentHandler.
SDL Tridion's own Dreamweaver Templating implementation has such a handler. I've just looked at the Razor implementation, and it currently makes use of the Dreamweaver content handler. Obviously, YMMV for the various XSLT template type implementations that exist.
As this is an extensibility point of SDL Tridion, whether included references will work "correctly" in lower publications depends on the implementer's view of what that would mean.
One interesting possibility is to implement your own custom handler that behaves as you wish. The template type configuration (in the Tridion Content Manager configuration file) allows for the mediator and content handler for a given template type to be specified independently, which means you could potentially customise the content handling behaviour for an existing template type.