Earlier today, myself, Tanner Brine and Dominic Cronin presented at the bi-monthly SDL Tridion webinar. Follow this link to download all materials for both presentations.
I have often come in on projects where a lot of the component templates are ‘dynamic’. Nothing wrong with that in itself, but when I have asked the question Why? the answers start to give me the feeling that the Dynamic Component Presentation (DCP) is a bit of a misunderstood animal.
In this post I don’t intend to teach you what a DCP is, or talk about any technical details of using them. Rather I explore the reasons that are often given for using DCPs, debunk some myths, and hopefully make you think a bit more carefully when making that decision to select the “Published as a Dynamic Component” option.
I’m seeing challenges and confusion with BluePrinting and Targeting in BluePrint workshops and in discussions about profiling and personalization. Don’t let the rise of “Customer Experience Management” (CXM or CEM for TLA fans) adversely affect your SDL Tridion BluePrint. Localization != Personalization (!= is code, literally, for “not equals”).
Creating a architecture presentation the other day helped to crystallise some thoughts in my head on integrating a CMS like Tridion, and Content Delivery Networks (CDNs).
I have been involved with such matters before (see my SDL Tridion World Article on how to technically integrate a CDN through Storage Extensions) but I thought it was worth sharing my ideas on the considerations when working with a CMS and CDN.
SDL Tridion’s Enterprise Content Management features are a good match for companies with a truly global digital presence and audience. Such companies are also those most likely to benefit from the scaling features offered by a global Content Delivery Network, so Tridion + CDN is a hot topic.
After you have been developing with SDL Tridion for a while, its easy to be a bit blasé about Schemas. Thats the easy bit right? Bung a few fields in, mandatory or not? multi-value? Configure the RTF fields a bit and off we go… on to the tricky parts: templates, integrations with 3rd party systems, automation etc. etc.
Making a schema is so simple that it is easy to forget how complex good schema design is. In this article I hope to bring a reminder to implementors of all levels of ability just what makes good schema design.