TPL recommendations

The core purpose of TPL is to make it easy to describe the most common structures to be modeled, while remaining powerful enough to describe the vast majority of modeling situations. While the power of TPL enables you to describe the vast majority of modeling situations, it does not prevent you creating patterns that cause unwanted, or unexpected behavior.

This page details recommendations for using TPL. Following these recommendation will prevent unwanted behavior.

Never create or modify DDD nodes

You should only ever add additional attributes to inferred nodes. You must never create or update DDD nodes.

Never modify system created attributes

When writing custom TPL you should never modify system created attributes. Rather, you should add new attributes using _tw_meta_data_attrs as described in adding custom attributes.

System created attributes are those present in the default taxonomy. You can see whether your taxonomy is customized by checking for additional custom files on the Files tab of the Taxonomy page.

Use related.host rather than model.host

The related.host function should be used rather than the deprecated model.host function. The model.host function, with a lower-case "h" has an unfortunate clash with model.Host with an upper-case "H", which creates or updates an existing Host node.

Avoid modifying TKU patterns

When writing TPL patterns it is recommended that you do not modify TKU patterns. If you do modify a TKU pattern, it will be overwritten when you install a later TKU. When writing a pattern to override a TKU pattern, you should use the overrides statement in the pattern declaration.

Avoid custom pattern module name collision

Custom pattern does not trigger if the custom module name collides with a TKU module name. There is no error or warning; it just silently fails when scanning. To avoid this you can add a name, for example the company name, ACME_ at the beginning of any custom pattern name, custom module name, and custom attribute name.