Tridion and ASP.NET MVC3

August 24, 2011

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>
<h1>@Model.Component.Fields["title"].value</h1>
<p>
@Model.Component.Fields["articlebody"].value
</p>

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
<h1>@Model.Title</h1>
<p>
@Model.BodyText
</p>

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: http://code.google.com/p/dynamic-delivery-4-tridion/

Pro’s and con’s

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

Pro’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).

Con’s

  • (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)

Contributors

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.

Advertisements