Patterns - TridionPractice/tridion-practice GitHub Wiki

Introduction

This page outlines Tridion design approaches and patterns in the spirit of Software Design Patterns. See Practices for Tridion implementation recommendations.

List

Potential Patterns

Output HTML

Overview

  • Templates output markup such as HTML4, XHTML, HTML5, etc
  • Page Template extension may be .htm or .html

Benefits

  • Simple, easy-to-create, near out-of-the-box implementation
  • Designers can create DWT layout

Trade-offs

  • Lacks presentation server logic except for JavaScript

Output Non-HTML

Overview

  • Tridion publishes pages with standard component presentations into an intermediate format (.NET, .JSP, or agnostic formats such as XML/ JSON)

Benefits

  • Flexible and familiar datasource
  • Content Consuming developers need less Tridion experience
  • Platform agnostic--similar sources can be used across channels, sites, technologies (.NET vs Java), etc
  • Flexibility in handling content, metadata, and multimedia in render-side logic

Trade-offs

  • Designers lose access to DWT or must understand/be allowed to use the rendering framework format
  • XML, JSON, and other formats are stricter than HTML
  • Format and self-managed standards apply for the output
  • Troubleshooting involves queries rather than just rendered output (e.g. check database, metadata, templates, tcm ids, etc)

Examples

  • DD4T
  • CWA
  • Most Tridion-using organizations that have .NET or Java websites

CM-Side Rendering ("Baked")

  • Familiar API to Tridion consultants
  • Impacts publishing performance
  • Possibly improves rendering performance
  • "Static" snapshot of CM-side relationships may not reflect published CPs

CD-Side Rendering ("Fried")

  • Implementaton may optionally use CD API with dynamic component presentations and custom metadata
  • Object (and query) caching provides fast results when using CD-API specific approach
  • Improves CM-side performance
  • Improves publishing performance
  • Retrieves and displays only published CPs

Navigation by Structure Groups

  • "Classic" navigation approach includes generating a navigation file, typically XML
  • XSLT or code transforms XML into appropriate markup
  • Standard, well-known, and documented approach
  • Straightforward author-friendly navigation management

Recursive Defaults

Based on the premise that good defaults improve the author experience and improves output.

  • Use a value in the lowest, most specific context (for example "alt" text from a schema that links to an image or page SEO information)
  • If value not available, use the value in the next higher, less specific context (e.g. if article component doesn't have SEO information, check page)
  • If value still not available, recursively check higher and higher items (e.g. check page, then check parent SG, then parent's parent, all the way to root or publication metadata)

Note: to follow translation best practices, use components instead of page/SG metadata.

Considerations

The appropriateness of a particular design pattern depends on the target development environment, consider the following when choosing an approach.

  • People - project and long-term resources, skill level, and number of individuals and teams
  • Process - organizational standards, measurements, cost structure, and incentives
  • Technology - software versions, rendering framework (.NET or Java), and hardware