In this article I will try to explain the basic structure of SDL Tridion. I hope to give an easy to understand glance to the system.

First let’s start with explaining what SDL Tridion actually is.

  1. What is this thing Tridion or who the f* is Alice?

    Tridion is an enterprise solution for big sites that usually support many languages and media platforms. The license for the system is paid. Basically SDL Tridion is a powerful CMS (Content Management System) and is used mainly by big corporate clients. Its’ main advantage is the easy reusing of a part of a site (design, content, etc.) for the creation of different sub sites, for example on another language. The bottom line is that if it is configured in the right way, Tridion allows common users to manage the content (for example to translate it) without any technical effort. The Tridion system has 2 parts, the Content Manager is written in .NET and the Tridion Content Delivery System is written natively in Java and available in .Net via Juggernet. I have been working with the .NET Content Delivery APIs. The information can be reached by the CD (content delivery) API, which comes in 2 main flavors: OData web service or Content Delivery API.

  2. Structure or how everything is connected

    • Content Management (CM) and Content delivery (Broker)

      Tridion works with two databases. The first one – CM is accessible only from the people managing the site. Like an administration panel, it has a convenient GUI that allows easy management of all the content. To show anything on the real site it needs to be published and it goes to the other database – the Broker. Publishing is a one Way Street, meaning information goes from CM to the Broker only, and the Broker cannot request the CM for anything. For the publishing the system uses Deployers. More about the deployer configuration check here.

      To understand Tridion first you need to now the organization of its components.

    • Blue printing e.g. the fancy words for inheritance

      At the top level in Tridion are publications. Everything is placed in a publication. Good practice is to have one top publication “Empty master”, one for Schemas, one for Content, one for Design, one for Pages and one for every site that you have. This is of course not mandatory and it can be done in many ways (for example an interesting structure is the creation of a root publication for every language, another root publication for every country and child publication that inherits the country and the language and that is the live website. This is example is convenient if we need a site that is for several countries and for each country we have several languages). Each publication can have multiple parent publications. Everything from the parents is accessible in the children and it is by reference so it’s the same everywhere. If something needs to be changed only in some specific child it can be localized and its content loses connection with the parent.

      blue-printing

    • Folders or what is inside the box

      tridion-folders

      In every publication we can have three types of folders: building blocks, structure groups and categories and keywords.

      •    In the building blocks we put our components, schemas, template building blocks, and component and page templates.
        • schema – contains the definition of content entry fields
        • component – the container for content
        • component template – the design for component content
        • page template – the design for page layout
        • template building block – the template (Dreamweaver, etc.) for the design used in the component or page template
        • target group – defines permissions

        building-blocks-elements

        Photo credits: Alvin Reyes

      •     The structure groups are the real site. There is only one root and can contains many substructure groups. This is basically the file system on the server shown through the Tridion GUI. Every folder here has a name and directory. The name is used only by Tridion, and the directories are the path that will be in the url and in the file system of the server. In the structure groups are the final pages. Every page is a combination of one or more components with a specific schema, and can use metadata schema with additional info (for example if we are working with .aspx pages, then in the schema can be the information about the .master page).
        • default page template – defines the schema of the page (for example .NET master page and file extension .html, .master, .aspx, etc.)

         stucture-groups-elements

        Photo credits: Alvin Reyes

      •     The categories and the keywords are used to classify content in CM. This is a way to create a knowledge map to the elements.One interesting usage of keywords can be labeling. This can be done with creation of a special category “Text Labels” that contains words for part of the page that are not in components (greetings, company name and address, e.c). Down the chain they can be easily localized and translated.

        categories-and-keywords

    • The connection

      The image below gives a basic example of how the things are combined for creation of a page.

      tridion-components-conection1

      Photo credits: http://www.sdltridionworld.com/images/

          And the interaction that’s leading to publishing.

       tridion-components-conection2

      Photo credits: Alvin Reyes

         As everything is connected the function “Where used” come very handy in Tridon. It allows you to easily move around the tree to find where something is used, where is published, and what is using.

  3. Mediators or don’t get lost in Translation

        There are three template syntaxes in Tridion: XSLT, Dreamweaver and Razor. For the first two, they had great expectations but never came true. So now everyone talks about the Razor Mediator. It’s clean, it’s by default in asp.net MVC applications, so we expect it to become viral in the Tridion development world.  At the moment the library for Razor mediator is open-source and is not officially supported by Tridion.

        For more check this very nice article about mediators in Tridion.

  4. DD4T vs. old style – get only what you need from Tridion

    There are two ways on which you can write your code:  depending on representation or depending on content.

    The Dreamweaver and XSLT syntaxes are currently the officially supported by Tridion and required the using of not very clean syntax for looping over the components and adding conditional statements. Their integration with asp.net applications is difficult, mainly because their syntax not supported in .NET, and the local work with the code becomes hard and debugging is a real challenge. You have to constantly save your work in Tridion, republish the page and check to see you get the expected change. And when you’re done working on the templates, everything needs to be republished. The focus is not so much on the pure content but on its representation.

    DD4T (Dynamic delivery for Tridion) is the new way of doing things. It’s relies only on the data – the components and all the presentation is done in clear .NET code. DD4T contains a set of templates that can publish any component or page as a full structured XML document to the content broker. It’s an open source library and it’s not officially supported by Tridion. Nevertheless DD4T’s license allows you to do anything with the code, as long as you do not change the original license and it has great community that can help you with your work.

This is only the tip of the tip of the iceberg but I hope that this article gives some basic knowledge to the reader. Have a nice time with Tridion.

For more information the official Tridion forum and the official site of SDL Tridion.

Author: Elena Kirilova