DD4T: How I stopped worrying about templates and love the Tridion broker

Original source of picture: https://www.flickr.com/photos/sloverton/

Development of Tridion websites has not always been an easy thing to do. In this blogpost I want to talk about a framework that shows you that it doesn’t necessary need to be this way. DD4T is a framework I’ve co-developed with some other Tridion veterans and used in my most recent projects. The framework makes it easier for Tridion developers to develop, deploy and maintain a project.

The challenge most developers encounter when starting Tridion development is the development workflow. We all know what a proper workflow can do for your productivity. Things get done quicker and more efficient. The focus of the DD4T project is to bring a more web developer centered approach to Tridion projects.

As a Tridion developer writing templates and presentation code can be a daunting task. 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. Debugging is hardly possible, making it more time consuming to fix it. If you’re working in a team, it can get even more difficult when you’re touching the same templates. DWT or XSLT code is saved directly in Tridion and not in a version control system, making it impossible to merge, branch or tag your code

Introducing DD4T

As said earlier, with DD4T there is another approach to develop Tridion projects. You’re no longer required to do everything in a small source tab in Tridion. Yes, you can use your favorite IDE to develop the project locally and the project can be shared with a team through a version control system of choice.

So, how does it work? Traditionally, the templates you create in Tridion create HTML/JSP/ASPX files that are published to the deployer and deployed as files on your presentation server. Dynamic component presentations contain pieces of HTML that are published to the Content Broker, that can be reassembled on a JSP/ASPX page. Because Tridion projects are split into a template side of things and a presentation side of things, you have 2 APIs (and sometimes multiple languages) to worry about.

Shorter and less costly

DD4T can make your implementation shorter and less costly in a couple of ways.

  1. There is less need for republishing when updating functionality. DD4T contains a set of templates that can publish any component or page as a full structured XML document to the content broker. These XMLs contain anything you need to build up your pages from the presentation side and makes it very easy to change functionality at any stage of your project, without the need to republish anything.
  2. Functionality can be deployed much quicker and feedback can be gathered a lot earlier. This makes DD4T the first choice for teams that want an agile approach to Tridion projects. Deploying a DD4T website is like deploying any webapplication and can be integrated in a continuous integration workflow where your application is always deployment ready.
  3. .NET and Java developers can start working on functionality right away, without the need to go through all the hassle of learning Tridion templating first. They only need to know about the basic concepts of Tridion and can work on a DD4T project from there.

Dependency Injection

Dependency injection is a way to make software more pluggable and reusable. Most developers have seen the benefits of using this pattern and in DD4T it has been used extensively for 2 reasons:

  1. A greater independence of the CMS behind it. In other words, a website implementing DD4T should be able to change CMS behind the website relatively easy.
  2. More unit testable code. The implementations in DD4T all have an interface that can be mocked with mock frameworks, such as Moq, making it possible to test your controllers with predefined models of the components and pages. You can run tests over and over to make sure all functionality still works as expected after making changes.


Open source and support

DD4T is released under the Apache license. This license allows you to do anything with the code, as long as you do not change the original license on the code. You can download the code, modify it, share it with someone else and a lot more. Open sourcing the code allows everybody to read the code and provide fixes that can make the framework a better product.

There is one small thing to take in consideration when you’re going to use DD4T. DD4T is not supported by SDL. SDL will only support the default installation and APIs that come out of the box. Because it’s open source however, makes it possible for anyone with enough knowledge about the framework to download the source, fix it and create a patch in a much faster way. Also, there is a great community out there to answer your questions and provide you with necessary guidance.

If you need a partner to implement your Tridion project with DD4T, Indivirtual has both strong Tridion and Java/.NET skills to help you with your implementation.

Kah Tang

Kah Tang is a senior web developer with years of experience in Tridion, .NET and Java. He joined Indivirtual in 2006 to make the web a little better, one line of code at a time. You can also wake him up in the middle of the night for some good boardgames, Android, iOS and NodeJS.

  • S A P

    Thanks for the info on the blog Kah Tang.

    Planning to migrate a site from SDL Tridion to Adobe Experience Manager. The site currently uses DD4t with Spring MVC. What are the changes required at the web application level [specifically code that uses org.dd4t packages]?

    I see that in your blog, you are suggesting that there should not be any impact to the web application at all. Would DD4t work with another CMS system seamlessly?