I hear requests for "Tridion [industry] best practices" at least monthly in both internal and external discussion. Implementers ask for them, colleagues forward emails about them, and trainees ponder what constitutes a best practice.
The answer unfortunately, in characteristic consulting fashion, is "it depends." The best
practice depends on your environment and business needs. Lets see how context impacts:
- Why we want best practices
- Tridion best practices
- The discussion on Tridion patterns
Why Best Practices?
Easy. We want to know the biggest issues we'll face implementing feature XYZ.
- What have others done to get XYZ?
- How should we build XYZ?
- What are the typical "newbie" mistakes with XYZ?
Lots of time, trials, and tribulations produce such practices. So they're invaluable but not without context. A misguided focus on best practices distracts you from understanding your particular needs. Yes, we have to think and I know sometimes its a pain in the ass, hence the term analyze (Ooh, did you get that? Nevermind. Move along to the examples).
Tridion Best Practice Examples
In order to apply to everyone, the ultimate practices are so generic, bland, and boring they approach becoming platitudes
such as "use a content management system to manage your content." You might hear best practices familiar to any
- Don't hard-code values.
- Use naming conventions and standards.
- Build so that the likely-to-change parts are easy to change.
- Separate concerns.
My favorite is "the best practice is one that works" ("Knew Know
", multiple citations circa 2000-something up to this post and beyond). But let's add some Tridion-specific detail.
- Don't hard-code Tridion Content Manager Identifiers (tcm ids) when possible. Actually, never! Well, except maybe in questions to make it clear what you're doing, but even then someone's going to copy your code... See? Best Practice discovery isn't simple.
- Use friendly names for author-facing items such as templates and schema but geek-out with your favorite naming conventions for developer-specific items such as embeddable schema.
- Build for change by using configurable system components, source control for assemblies, and extensions, not customization. Place template-related content in components to avoid needing to localize templates for, well... content differences.
- Separate concerns by using a tiered architecture; managing content, design, and pages in different publications; and having content management and delivery in different environments.
You should also reveal the "we could build it this or that way, but won't" options. Let's make sure the system works, but just because you can
do it a certain way doesn't mean you should, it depends on... let's say it again, context.