Avoid hard-coded TCM URIs in Tridion code

Question

We often need certain elements (circuits, templates, or components) in the code associated with Tridion. A template, content delivery, workflow, or business service (Core Service) regularly needs links to the URI Tridion Content Manager URI . We can reference components, but I usually see either hard-coded values ​​or WebDAV URLs for everything else.

Hard coded values

I understand that the Tridion Content Manager (Native) URI hard code is bad practice, with the exception of a few scenarios:

• To simplify the code example and make clear what a variable is
• When created for use in logic, Content Delivery API (CD)

Whenever possible, we use the specified API or WebDAV URLs to refer to elements, otherwise we should avoid using the Content Porter in everything that refers to the TCM URI (or somehow make these links “custom” outside Tridion).

WebDav URL

WebDAV URLs look better for several reasons:

• Hard-coded values ​​in Template Building Blocks (TBB) or other template formats remain intact with the SDL Content Porter (breaking relationships when moving through CMS environments with the exception described below).
• Configuration components that reference specific elements also work better with the SDL Content Porter, although differently named paths can break the relationship.

Use cases

In addition to a template that works well with Content Porter, I would like to localize folders and / or structure groups in lower publications. This can help:

• CMS authors who read different languages
• translate names and paths into appropriate languages.
• may help users better navigate (for example, I suspect folders with different names may reduce confusion when authors are in BluePrint)

One approach

To make Content Porter-friendly links, at least for Template Building Blocks, I know that we can use WebDAV Urls in components to localize each path to the right places in child publications. For example:

• Code Verification Publication Metadata
• Publication metadata points to "configuration component"
• Config Component Has Paths As WebDAV URL

As long as we set the publication metadata and localize the fields in the correct publication paths, this will work for most scenarios.

Questions

• I got it right? Is there a simpler or easier to maintain setup?

I believe that we can alternatively use includes or display an unmanaged URI in the template code .

• Does anyone have an example #include approach? . I use this at the top of TBB and / or DWT, and links are replaced independently of the Template Mediator (for example, does this work with an XSLT broker, a razor broker, etc.?)

• Does reference work include in lower publications or is it just for Content Porter? In other words, if I refer to "tcm: 5-123", does the template correctly refer to "tcm: 17-123" in publication 17?

Answer 1

I try to follow a few simple rules ...

• There is no single reasonable reason to ever use the TCM identifier in everything - template code, configuration components, configuration files.
• If I need webdav URLs in the configuration, I try to always make them “relative”, usually starting with “/ 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, to the extent possible, to use them. (managed links are the xlink:href tags that you see throughout Tridion XML).

I also tend to use the “configuration page” for content delivery, with a template that displays TCM identifiers that I might need to “know” from the content delivery application. It then loads at run time as a set of configuration variables or as a dictionary or as a set of constants (I think it depends on how I feel on this day).

Answer 2

Although we usually refer to the implementation of a template type as a template broker, this is not the whole story. An implementation of a template type consists of both a template broker and a template content handler , although the latter is optional. Whether this implementation will handle "includes" correctly does not depend on the intermediary, but on the processor.

You can find a good starting point in a document by doing an AbstractTemplateContentHandler search.

SDL Tridion's own implementation of Dreamweaver Templating has such a handler. I just looked at the Razor implementation and it currently uses the Dreamweaver content handler. Obviously YMMV for the various existing XSLT template type types.

Since this is the extensibility point of the SDL Tridion, included links will work “correctly” in lower publications, depending on the developer's understanding of what this means.

One interesting opportunity is to implement your own custom handler, which behaves as it sees fit. Template type configuration (in the Tridion Content Manager configuration file) allows you to specify a broker and content handler for a specific template type independently, which means that you can configure the content processing behavior for an existing template type.