Tag Archives: MVC

DD4T.Web: Publication Resolving

The next DD4T release (1.30) which will be out shortly, features a new .NET library: DD4T.Web. This library contains functionality which can be used within a .NET web application, regardless of whether you are using MVC or not. In a short series I will introduce the most important functionality in this library. This episode: Publication Resolving.


DD4T is all about URLs. When the request comes in, the framework looks in the Tridion broker database for pages with a matching URL. Or rather: a matching path. For example: if the URL is http://www.acme.com/products/foobar.html, the path is /products/foobar.html.

But what if there are more matches? This is entirely possible because of Tridion’s BluePrinting model. Imagine the Acme corporation decides to launch a German web site, with the base URL http://www.acme.de. They manage this site in a Tridion publication which is a child of their ‘dotcom publication’ (which manages the www.acme.com site). Given the nature of BluePrinting, the German page about their ‘Foobar’ product, will have the url http://www.acme.de/products/foobar.html, and the path of this page is /products/foobar.html.

As you see, the path is identical to the path in the English publication. So how can DD4T tell which page to serve? This is done by the PublicationResolver. This is a very simple class, whose job it is to find out which publication the current request belongs to. In the example above, the PublicationResolver could look at the host name and return the correct publication id: if the host name is ‘www.acme.de’, it should return the id of the German publication, if it’s ‘www.acme.com’ it returns the id of the DotCom publication.

Resolving the publication based on the host name is an obvious choice in many cases, but there are alternative scenarios. For example: you could look at the preferred browser language and base the publication id on that. So: if my browser language is German, I will see the German site, regardless of the host name. Technically, I wouldn’t need the www.acme.de domain at all (although I don’t think Google will like it if the same URL can return a page in different languages!)

And then there is the simplest form of all: you can simply decide that all the requests in your web application should use the same publication id. This is actually the default behavior. DD4T comes with one implementation of the PublicationResolver interface, the DefaultPublicationResolver, and it simply looks in the Web.config for an appSetting called ‘DD4T.PublicationId’. This id is then used to look up all the pages, components and binaries. The downside is of course that you need to set up a separate web application for each language that you’re supporting. Not very efficient and tough to manage!


Implement your own resolver

It’s very easy to write your own publication resolver.

  • First, create a class library project in Visual Studio.
  • Add a class which implements the DD4T.ContentModel.Contracts.Resolvers.IPublicationResolver.  
  • Right-click the word IPublicationResolver and select ‘implement interface’.

Your code now looks like this:

using System;
using System.Web;
using DD4T.ContentModel.Contracts.Resolvers;

namespace Trivident.DD4T.Examples.PublicationResolvers
   public class HostNamePublicationResolver : IPublicationResolver
      public int ResolvePublicationId()

As you see, this interface defines only one method: ResolvePublicationId(). In that method, we will check the host name in the URL and use it to determine the publication id. In a very simple (not to say a moronic) form, the code might look like this:

using System;
using System.Web;
using DD4T.ContentModel.Contracts.Resolvers;

namespace Trivident.DD4T.Examples.PublicationResolvers
   public class HostNamePublicationResolver : IPublicationResolver
      public int ResolvePublicationId()
         switch (HttpContext.Current.Request.Url.Host)
            case "www.acme.de":
               return 17;
            case "www.acme.com":
               return 16;
         throw new InvalidOperationException(string.Format("unknown hostname '{0}", HttpContext.Current.Request.Url.Host));

In a real life implementation you would probably want to get rid of the hardcoded IDs, but the point is clear, I hope.

Using  it in your application

The PublicationResolver is a property of the factories (PageFactory, ComponentFactory, BinaryFactory, LinkFactory). If you’re using a dependency injection framework (like MEF or Unity) you can simply configure it as a dependency of those factories. Otherwise, you can set it manually (in code). In your PageController for example:


private IPageFactory _pageFactory = null;
public override ContentModel.Factories.IPageFactory PageFactory
      if (_pageFactory == null)
         _pageFactory = base.PageFactory;
         _pageFactory.PublicationResolver = new HostNamePublicationResolver();
      return _pageFactory;


Using DD4T without publication resolving

It’s possible to use DD4T without doing any publication resolving. In that case the publication is not used when looking up the page in the broker database. This works if all the paths in your system are unique. So in our Acme example, the URLs of the English and German ‘foobar’ pages should be:

  • http://www.acme.com/products/foobar.html (English)
  • http://www.acme.com/de/products/foobar.html (German)

In this case, DD4T can and will always find the correct page.

If ‘the business’ can live with this style of URL, then go for it. It saves you the trouble of resolving anything!

To use this approach, just use the default publication resolver (this requires no action) and remove the key ‘DD4T.PublicationId’ from the Web.config.





Inside DD4T: templates without metadata

If you’re using DD4T, you know that you have to assign metadata to your templates. It is through this metadata that DD4T knows which view to use to render a given page or component presentation.

Now, DD4T can also work without metadata on templates. How? Simple: by using a naming convention. Just give your view the same name as your template, and you’re done.  This is in line with the ‘convention over configuration’ mechanism which is embraced by the MVC world.

There is one caveat: if your template name contains spaces, these are removed before looking up the view. So if your page template is called ‘Standard Mobile’, the file containing the view should be named ‘StandardMobile.cshtml’.

Of course, the good old metadata still works, and will continue to be supported as a way to override the default.


Mixing content and functionality with DD4T

Today I received a question from a developer who is just starting on DD4T. He wants to have a page which consists of regular Tridion content but also contains a form. Being a .NET MVC developer he naturally wants to handle this form with a controller and various  actions to handle GET and POST and perform validation as well as sending an email on successful submission.

I call this type of web page, which combines plain content with application logic, a ‘mixed’ or ‘hybrid’ page. DD4T was designed to handle such pages (as well as the more simple content pages). To understand how DD4T does this, you need to know that the framework uses controllers and actions on two different levels:

  • The level of the page (just like in any MVC app)
  • The level of the component presentation

Let’s start by looking at a very simple page, which does NOT contain any forms or other application logic:


As you see, there are two views involved to build this rather simple page. The controller and action are predefined by the framework – unless you override them, which I will explain later. The controller/action for the page retrieves the page from the Tridion broker and uses that as its model. The controller/action for the component uses the component as its model. All YOU need to do is write the views.

You may wonder how DD4T knows which views to call. This is achieved by configuring the name of the view in the metadata of the page template and component template.

Now I’m coming back to the question of mixed pages. A mixed page has application logic as well as plain content. To handle application logic in MVC, you need a controller and an action. For example: you might want to display a form when the method is GET, and validate it when the method is POST.

In a diagram, this is how it will look:

The page now contains two component presentations: one that represents (and contains) just plain content and another one that represents the form. The neat thing is that your custom action will automatically be called by DD4T. All you need to do is configure your custom controller and action using metadata on the component template. So instead of just specifying a view, you will now have to specify a controller and action as well.

Advantages of this ‘mixed page’ approach:

  • Tridion stays in control of the URL
  • Editors can decide where to put a form, and which other pieces of content to put next to it
  • The placement of the form and other pieces of content is handled by the exact same view as on normal pages, so you do not have to do extra coding.
  • All MVC functionality like model binding and validation are fully supported

Happy coding!


What is DD4T and why should I care?

Imagine this: you are an engineer or web developer, and the company you work for has just got itself a license for Tridion. So they send you off to get yourself trained. After a grueling week of getting to grips with Yet Another Complex Piece of Software, you feel that you at least understand the basics. You have created your first schema, written your first template, and you just can’t wait to build your first web site – until you run into some guy at the coffee machine, who asks you if you shouldn’t be using “DD4T”.

Sound familiar? Keep reading! In this post I will explain what DD4T is, and why it might or might not be useful for you.

DD4T is short for Dynamic Delivery for Tridion. It is a thin layer of functionality on top of the Tridion APIs that exposes the Tridion object model to dynamic web applications. The goal of DD4T is to allow you to develop a Tridion-based web application directly, without having to code templates.

Maybe a picture will make this clearer. The “classic” Tridion style of implementation (which is still used in 95% of the cases) looks like this:

blog - template development

The logic of your web site is built by a template developer. However, he or she does not develop this logic directly. They write templates which operate on the content management server. These templates generate server / client logic that runs on the web application server.

About two years ago, a group of seasoned Tridion geeks decided that this was no longer the way of the future. The templating approach – they felt – was prohibiting them from using their favourite web development tools optimally. The java-fans among them would really like to develop web apps with Spring MVC, using Eclipse as their IDE, and storing all the code in Git or SVN. The .NET-buffs were dying to write their sites in ASP.NET MVC, using Visual Studio and Team Foundation Server.

They decided there was another way. Before long, their initiative had a name – DD4T – and a home on the internet. The open source project was launched in September 2011.

Compared to a templating implementation, a DD4T implementation looks slightly but significantly different:

blog - dynamic development

Here, the template developer has been replaced by a web (application) developer, who writes his/her code directly in a web application environment.

Of course, that does not mean that the developer is working in the same environment as the people visiting your site. You would normally set up a development environment for this. Or better still: each developer can develop and run / debug the entire web application on his own work station. But logically, there is no difference between what the developer sees and what the visitors of your site see.

This paves the way for the total leverage of Visual Studio, or Eclipse, or whichever programming environment the developer happens to be a fan of.

The DD4T approach has many advantages, not only for developers, but also for their managers, as well as the content editors / marketers who actually use Tridion to manage their web sites. I’ll try to sum them up.

Advantages for developers

  • Developers have Intellisense for the code that really matters: the .NET / Java code that makes up the web site
  • They can use step-through debugging for the web application
  • They can use unit tests to check the consistency of the website after every change
  • They can store their code in a source code management system (like TFS, Git or SVN)
  • They can make local changes without interfering with the other developers on the team
  • And most importantly: they can take their skills in creating .NET / Java web applications and put them to use very easily, without having to deal with the complex and often confusing ‘detour’ of templating


Advantages for IT / project managers

  • Teams are much easier and cheaper to staff (there are many more .NET / Java developers than there are Tridion developers)
  • Even if your team is lacking the required .NET / Java skills, it is much easier to train them, with all the available resources on the net
  • Better leverage of investments in developer tooling (e.g. SCM, automated build systems, etc)
  • A new version of the entire site can be deployed at the click of a button (without lengthy republishing of entire site)
  • Very well suited for agile development processes
  • Releases can be managed better (they can be planned more easily, rolled back more easily, etc)


Advantages for editors

  • Publishing is much quicker (because the templates are very simple)
  • They don’t have to wait so long for  bugs to be fixed and enhancements to be made


Of course there are some disadvantages as well. When you decide to go with DD4T, you are not going to use Tridion as a web site development platform, but only as a content management platform. Hence, changes to your web site cannot (easily) be deployed by publishing from Tridion. Instead, you need a separate web development platform, for example Visual Studio + TFS (or Eclipse + Git/SVN if you’re building a java web site). If you do not already have such a development environment, you are incurring extra costs.

A second drawback is the fact that DD4T is not supported by SDL. That sounds more dramatic than it really is. Tridion only supports its own public APIs, not the code that customers write on top of it. In a ‘classic’ Tridion implementation, the template code is not covered by your support contract with SDL Tridion. However, the interaction of your templates with the Tridion API is completely supported.

Similarly, DD4T itself is not supported by Tridion, but the calls it makes to the Tridion API are. And since DD4T is open source, you have unrestricted access to the source code. On top of that, the framework is supported by an active community, consisting of long-time Tridion experts.


A lot has happened in the last year. Big companies have decided that the pros outweighed the cons, and have launched web sites based on this framework. Even more are busy migrating towards DD4T, or are staging proofs of concept. SDL itself has recently launched its new flagship web site, completely built on DD4T. It may still be a relatively new initiative, but that is apparently not stopping them from giving it a try!



DD4T is a very attractive alternative to templating as a way to build web sites out of Tridion. It makes the lives of your developers easier, resulting in a shorter time to market and a higher quality of work. Plus it makes it much easier to deploy changes. The main caveat is that the framework itself is not part of the Tridion product suite, and as such not formally supported.

The value of DD4T is demonstrated by the fact that many Tridion customers are either switching to it, or are seriously considering switching. If you own or support a Tridion-driven web site, you should at least give this some consideration.

Ready to try it out, or just interested in finding out more? Go to http://code.google.com/p/dynamic-delivery-4-tridion/.