CODEWITHSUNDEEP
tridion
Alvin Reyes
Alvin Reyes

Reputation: 2887

Avoid hard-coded TCM URI in Tridion-Related Code

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:

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:

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:

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:

  1. Code checks Publication Metadata
  2. Publication Metadata points to a "config component"
  3. 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

I believe we can alternatively use includes or map unmanaged URI in template code.

Upvotes: 7

Views: 1081

Answers (2)

Nuno Linhares
Nuno Linhares

Reputation: 10234

I tend to follow a few simple rules...

  1. There is no single valid reason to ever use a TCM ID in anything - template code, configuration components, configuration files.
  2. 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
  3. 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).

Upvotes: 6

Dominic Cronin
Dominic Cronin

Reputation: 6191

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.

Upvotes: 2

Related Questions