Tridion and ASP.NET MVC3

My current project involves (re)building a Intranet based on SDL Tridion 2009 and ASP.NET MVC3.
In this post I want to share how we set things up and how we build it.

The goal was to build a re-usable, flexible and -last but not least- opensource framework  on top of Tridion based on ASP.NET MVC3.
Re-usable so Tridion consultants can use it in all their projects. Flexible so functionality can be added easily and opensource so anybody can contribute.
Of course our first concern was to deliver a full-blown website based on SDL Tridion.

As you may know, MVC stands for Model, View, Controller and is a programming principle used in many languages, mostly in java based languages. Microsoft thought they couldn’t stand
at the sideline and watch, so they came up with their own implementation of MVC, and the called it, well ASP.NET MVC3. (3 being the version number. Version 4 is already in development)

To fulfill the 3 requirements for an MVC3 webapplication, you have to deliver/build the following parts:

  • Model          -> Can roughly be seen as the data coming from Tridion (Pages, components, etc.)
  • View             -> The markup to show the Data (Html)
  • Controller   -> The way how to get/build-up the Data and pass it to the View. In Tridion words: Connect to the Broker Database and build a Model.

To be able to build a Model from the data from Tridion on the Content Delivery side, this data must be stored in the Content Delivery Database. And this should be more than just meta-data because
we need to build a complete page, including ‘normal’ field-values to show on your website. To do this, we used the Tridion Dynamic Delivery Templating project. This (compound) templating project is developed by SDL Tridion and
creates XML from the components and pages. We then publish this XML to the broker database. Now the rough Model of our data (content) exists in the database and we need to pull it out in order to build a nice looking content-page.

How to get the data (content) and build a model

An ASP.NET MVC3 application uses a route-engine to route URL’s to Controllers. (based on the url-parts). In this Controller the Model is build and passed on to the View.
Since this paradigma goes for all URL’s the Dynamic Delivery Framework has a BaseController (inherits from Controller) which does this for you:
It uses the Factory’s project (to be precise the ‘PageFactory’) to query the broker for a page with a certain URL (the URL the user entered in the browser).
It then desirializes the XML returned from the broker into a Page (Dynamic Delivery Page) object and voila: you have your page model.
This Page contains all of the data needed to create a nice looking webpage. It contains for instance: Id, Title, FileName and last but not least: Componentpresentations.
The Page object almost looks like the Tridion Object Model Page-object. It contains most of the familiar properties.
Same goes for ComponentPresentation. This object contains the 2 most important properties: ComponentTemplate and Component.

How to visualize the Model

When you have build your Model in the controller, you have to pass it on to a view. A view is the visual representation of your Model.
ASP.NET Mvc3 ships with 2 view-engines: aspx and razor. We used the razor-engine to create our views.
Razor gives you the full power of C# to script your views. One of the main adavantages of razor-views
is that you can have typed-views. This means that you have full intellisense in your view!

You could write something like this in your view:

@model IComponentPresentation</pre>

This looks pretty familiar right? This could easily be taken to the next level. It would be nicer if your view is of type, lets say: Article. Well, this could easily be achieved by building your own Model out of the ComponentPresentation Model. In your Controller you would write something like this:

Article homepageArticle = new Article();
homepageArticle.Title = ComponentPresentation.Component.Fields["title"].value;
homepageArticle.BodyText = ComponentPresentation.Component.Fields["articlebody"].value;

If you then pass this Article-model into the view,  you can write your View as follows:

@model IArticle

Pretty nice isn’t it?

The Framework

The framework we build does almost all of the ‘standard ASP.NET MVC3’ actions for you. For instance it does this for you out of the box:

  • Query the broker to find the right page (using the Url)
  • Ability to render the componentpresentations separately.
  • Build an ASP.NET sitemap by using the XML published to the broker (template to render sitemap XML not yet included. Can be downloaded from the forum)
  • Link resolving
  • and much more.

You can download the project here:

Pro’s and con’s

Every development approach has it pro’s and con’s.


  • Separation of concerns (MVC)
  • Development
    Development is made easy because all you need is a Visual Studio environment and you are ready to go. You don’t need Tridion Content Delivery to be installed on every development machine.
    We build a WCF service which query’s the broker and returns all the XML we need. Developers only have to reference the WCF service and are ready to go. They don’t have to know much about
    Tridion. They can program as they are used to. Making Models, Views, etc.
  • Releasing
    Releasing changes is a copy-paste action. Copy some (versioned!) dll files into the bin-directory and you are done. Most of the time you don’t have to re-publish your whole site. If you have set up your views in a smart way (using master-views) you can for instance update your website layout by copy-pasting the new dll file and you are done. No need te re-publish.
  • Familiarity
    In ASP.NET MVC3 the same concepts as in Tridion are used. You can have a masterview (PageTemplate). You can have ‘partial views’ in a view (Placeholder in Pagetemplate where you render the ComponentPresentations).


  • (Layout)Changes are not applied in the usual way of publishing pages/components. But by copy-ing dll files. This is (very) different from publishing changes with Tridion for instance. (What the business is used too)
  • Preview in Tridion does not work out of the box. (It is possible, but it requires some work)


You are free to contribute. Just download the project from GitHub and get started! (There is a Quick start document in the Wiki)

There is a lot I didn’t tell because nobody wants to read a long, (boring) blogpost. If you need more info or want to ask questions: feel free to mail or make remarks in the comments.
I will add a follow up blogpost describing the framework in more detail if this is necessary. Let me know.

Updated to GA – Releasemanagement with SDL Tridion 2011

Finally I did find the time to update the releasemanagement extension to match the GA requirements.

I deleted a bunch of unnecessary files and updated the eXtension.config. Also updated part of the code to perform better.

You can download the new version here. There is an updated howto.txt included with install instructions.
(My previous post is also updated with the new downloadlink)

Releasemanagement with SDL Tridion 2011

One thing I always discover (again!) when I work on a Tridion project, is the lack of release management. We develop new schemas, templates, edit existing ones and maybe create (config)components.

Developers have to keep track of all these changed items, because when the release/project/fix is ready, it has to be installed on the other Tridion servers. Normally I kept track of the changed items using an excel sheet. But boy is that tedious.

After finishing development we always use Contentporter to port the new/edited items to the next environment. So I print the excel-sheet, open Contentporter and have to go through the list and select each item individually. This is besides annoying, also error prone.

I thought this could be automated. So I created an extension for the SDL Tridion 2011 CTP. It involves a context-menu extension and a ribbontoolbar extension.

Releasemanager context menu extension

You can add an item to a release by right-clicking on it. A popup is shown with all the available releases. You can select the release the item belongs to and you’re done.

When the release is ready to be installed on the other Tridion servers, all we have to do is create a Contentporter export- and import file. You can do this by clicking on the ‘Releasemanager’  button on the ribbontoolbar. It opens a popup which let you create the Contentporter files.

Releasesmanager SDL Tridion

With Contentporter 2009 you can easily use these Export- and Import settings file to create an export and later import this on the next Tridion environment.

When you open Contentporter 2009 you can choose from 4 options. If you select the 4th option ‘Load wizard settings from a file’, you can use the just created export/import files to create an export for your release.

After you are finished with the release there is an option to finalize the release. The items are removed from the Releasemanager DB (Xml file) and placed into an history folder. There is no functionality to restore the history or to look into the history. If this extension is something people need I will update it with this functionality. Also, the layout is just plain…well, there is none 😉 I just wanted this to work.

If you like this extension and you want to use it or you have enhancement request, please let me know. I may update this extension 🙂

Small note: Since Contentporter wasn’t installed on the CTP image, I could not test it fully. I did test it on another Tridion instance and it seemed to work 🙂

You can download the extension here. (Updated link) There is a howto.txt included with install instructions.