DD4T stands for Dynamic Delivery For Tridion and is a leightweight ASP.NET MVC framework build on top of the SDL Tridion stack. It’s opensource and you can find more about it here

XPM is the WYSIWYG editor (and much more!) that ships with SDL Tridion.

Domain Driven Development is… well, Wikipedia explains it better than I can, so check it out!

I am a big fan of the MVC framework from Microsoft. No wonder I also love the DD4T framework as it makes building MVC websites with SDL Tridion a LOT easier.
One of the shining features of SDL Tridion is its recently upgraded WYSIWYG editor (Or Experience Manager) that allows editors to edit the content of the website in the context of the website itself, in the browser.
This is a great feature and makes it very easy to adjust content in a natural way.

Of course, before content editors can use the Experience Manager (XPM from now on) the SDL Tridion consultant has to pull some triggers to make this possible. All relatively easy to do.

But with DD4T it’s not so straight-forward as one would want. And especially if you are doing (a form of) Domain Driven Development, and thus are using (domain)ViewModels.

Before you read on, I highly recommend that you read Kah Tang’s article on ViewModels in DD4T first. This is how I usually implement DD4T and helps you understand the problem we are trying to solve in this post.

I’ve see a few DD4T implementations, and most of them use the OOTB DD4T models as their ViewModels. (Don’t know what ViewModels are? See: http://stackoverflow.com/a/11064362/1221887)

For example, consider the following razor View (which also renders the XPM markup):

As you can see this View uses the DD4T ‘IComponent’ as it’s ViewModel. And it is using the OOTB DD4T ‘SiteEditField’ HtmlHelper to generate the XPM markup.
While using the IComponent as a ViewModel is valid, it’s not as nice and clean as it could be. Also, the developer has to know the name of the field in Tridion and there’s no compile time checking. While it’s a valid approach, it doesn’t leverage all the advantages of the MVC framework (for example: no strongly typed views).

I always use (domain) specific ViewModel’s. Using your own, domain specific ViewModels has many advantages from which ‘separation of concerns’ and intellisense are just two of them (IMHO).
ViewModels only purpose is to display the Model in a certain way. Sometimes they are (almost) identical to your Domain Model, but a ViewModel can/must have extra properties to make displaying it possible. It results in much clear views.

Consider the following example (not rendering the XPM markup):

As you can see it’s much cleaner and easier to read then the previous View and there is also no logic (checking, etc) involved. (I also could have used an HtmlHelper to write out the tag. It’s up to you.)

But what if your customer asked you to implement XPM? You cannot use the OOTB Html helper since your ViewModel doesn’t have the properties this helper expects.
Well, there are a few options.

1. Add the ‘IComponent’ as a complex property to your ViewModel.
This would look something like this:

It still requires the developer to know the names in Tridion and it’s lacking the strongly typed advantages. (Intellisense)

2. Add the XMP MarkUp as separate properties to your ViewModel:

This already looks cleaner and has intellisense. But I don’t like the added properties to the ViewModel. It clutters the ViewModel.

I struggled with this issue for quite some time. But after trying the above mentioned approaches I wasn’t happy with the result. Although it works, it isn’t as nice, clean and intuitive (for a programmer) as it could be.

After spending much time on it I came up with an approach. This approach involved quite some coding, but it’s for a good cause right? And I liked doing it, because I’ve learned a lot of new stuff.

I wanted it to be a generic solution, so everyone using DD4T could use it. This is how it looks like:
(It’s still a work in progress!)

1. Create your ViewModel and decorate it with attributes.
Example:

As you can see there are 2 new Attributes involved.

• InlineEditable
• InlineEditableField

The first attribute ‘InlineEditable’ marks the class (ViewModel) as inline-editable with XPM. The second attribute marks a single field as inline-editable with XPM.

Of course this is not everything. Once you created your ViewModel, you have to make a call to a method to do the magic. Since all my ViewModel’s by default are created inside a ModelFactory (a subject for a different post), I made this functionality part of a base-class, but you can implement it any way.
This is how my (simplified) ViewModel builder looks like:

That’s all. The article is now ready for XPM. It’s not yet inline editable, but the information from Tridion is added to the class, so we can use it in our View.

Let see how our View would look like if we would make this ViewModel (inline)editable with XPM:

As you can see we have full intellisense and a nice and clean View. Of course, I simplified the example a little, but it proves a point.

The XPM Helper and it’s ‘Editable’ method write out the actual value of the property and its corresponding XPM MarkUp.
There’s also a ‘MarkUp’ method that just write’s out the XPM MarkUp. This becomes handy when you want to make an image or hyperlink inline-editable:

All this is not yet part of DD4T, but I am planning on integrating it in the framework, as I see it as a valuable addition. (If not: let me know).
It encourages the use of (domain)ViewModel’s and results in a cleaner solution.

If you want to the XPM helper in you project now, drop me an email and I will send you the source-code and the instructions on how to set it up. In the end there’s really not much to it, but isn’t that the case with all challenges?

In this post I want to give you some hooks and pointers on where to look if things get interesting
In fact, if you are DESPERATE about why your Session Preview isn’t working, this post is aimed at you!

But first: thanks to Andrew Marchuk, Daniel and Likhan from SDL Tridion for helping me. Without their help I would still be staring at my screen

Well, let’s start!

(I’ll assume you have a basic understanding of SDL Tridion).

First, read this answer and the comments: http://stackoverflow.com/questions/10788508/continously-update-preview-alert-on-sdl-tridion-ui-2012/10802033#10802033

Meditate it, let it sink, adjust your setup and try again.

Now, if it still doesn’t work, read on:

First, turn of caching for your website. Just to be sure. After you got Session Preview working, turn on caching again and see what happens. But for troubleshooting the Session Preview I recommend to turn of caching completely. Just to be sure…

1. Do a basic sanity check and check the following for your staging website:

- Open the cd_storage_conf.xml from your staging website and ensure that:

• The

  <Wrapper> 

  element exists! Like this:

<Wrappers>
				<Wrapper Name="SessionWrapper">
					<Timeout>120000</Timeout>
					<Storage Type="persistence" Id="db-session-webservice" dialect="MSSQL"
					Class="com.tridion.storage.persistence.JPADAOFactory">
					<Pool Type="jdbc" Size="5" MonitorInterval="60" 
					IdleTimeout="120" CheckoutTimeout="120" />
					<DataSource Class="com.microsoft.sqlserver.jdbc.SQLServerDataSource">
						<Property Name="serverName" Value="WIN-1CJUK3HE34H" />
						<Property Name="portNumber" Value="1433" />
						<Property Name="databaseName" Value="Tridion_SessionPreview" />
						<Property Name="user" Value="TridionBrokerUser" />
						<Property Name="password" Value="PassWord" />
					</DataSource>
					</Storage>
				</Wrapper>
			</Wrappers>

Of course it should point to your SESSION PREVIEW database! Not to your default, ordinary Broker database.

• Check if at least the following StorageBinding is present in the cd_storage_conf.xml of your website:

<StorageBindings>			
                <Bundle src="preview_dao_bundle.xml"/>				          
            </StorageBindings>   

• Check if you added the AmbientData HttpModule (for .NET Sites!. For java it’s probably a filter) in the web.config of your website:

<add type="Tridion.ContentDelivery.AmbientData.HttpModule" name="AmbientFrameworkModule" preCondition="managedHandler" />

• If you are on a website that is NOT COMPLETELY DYNAMIC (so on a website that’s NOT ON DD4T) check if you added the following module in the web.config of your staging website:

<add name="PreviewContentModule" type="Tridion.ContentDelivery.Preview.Web.PreviewContentModule" />

Again: this module is NOT, I repeat NOT necessary if your website is a completely dynamic website. (e.g. retrieves everything from the broker like DD4T). If you still use this module, you will see that clicking on ‘Update Preview’ will generate files on the filesystem! And it will not show you the updated preview!

• Open the cd_ambient_conf.xml file of your Staging website and check if the following Cartridge is referenced:

  <Cartridge File="cd_webservice_preview_cartridge.xml"/>
  

2. Check the following for your OData Webservice: (The one that is used by the Session Preview, so the one you configured as the ‘Content Delivery Endpoint Url’ on your Publication Target)

• Copy/paste this ‘Content Delivery Endpoint Url’ and paste it into your browser. (Of course inside the company domain…) and see if it responds.

The url looks like this: http://localhost:73/odata.svc/
You should get a response with a listing of all collections that can be retrieved by this OData endpoint. Something along the lines of this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<service xml:base="http://localhost:73/odata.svc/" xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:edmx="http://schemas.microsoft.com/ado/2007/06/edmx" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
    <workspace>
        <atom:title>Default</atom:title>
        <collection href="Binaries">
            <atom:title>Binaries</atom:title>
        </collection>
        <collection href="BinaryVariants">
            <atom:title>BinaryVariants</atom:title>
        </collection>
  	....
	....
    </workspace>
</service>

• Open the cd_storage_conf.xml of your OData webservice and ensure that:
• The Wrapper tag is there and is pointing to your SESSION PREVIEW database. So not to your regular Broker Database!
• The StorageBinding with the preview dao bundle is there. Like this:

  <StorageBindings>			
                  <Bundle src="preview_dao_bundle.xml"/>				          
              </StorageBindings>   
  

• Open the cd_ambient_conf of your OData webservice and verify that:
  • The preview Cartridge is there. Like this:

    <Cartridge File="cd_webservice_preview_cartridge.xml"/>
    

Now, do an IISReset on your website and for your OData webservice. This makes sure that your changes to the various configuration files are used when the Content Delivery Instance boots up the first time. DO NOT SKIP THIS STEP! In case you are still in doubt: DO NOT SKIP THIS STEP! (Sorry for shouting)

Now, hit ‘Update Preview’ again. If it is still not working for whatever reason keep reading:

1. Open the logback.xml file of your Staging website, and set the loglevel to ‘VERBOSE’.
2. Open the logback.xml file of your OData webservice and set the loglevel to ‘VERBOSE’.
3. Clear both logfiles! (So you have a fresh start)
4. Clear the ‘Tridion’, ‘Tridion Content Manager’ and ‘Application’ Windows Eventlogs on the Content Manager Server
5. Clear the ‘Application’ Windows Eventlog on the Staging WebSite server
6. Clear the ‘Application’ Windows Eventlog on the Odata webservice server

Do an IISReset (You edited the logback.xml file, so this is necessary!)

Now, hit ‘Update Preview’ again and check out the logfiles in this order:

• cd_core.log of your Staging website
  -> Anything unusual? Especially error’s and warnings with regard to the Ambient Data Framework are important! Take them seriously and double check the cd_ambient_conf.xml and the cd_storage_conf.xml of your staging Website. Also, check if all HttpModules and/filters are present in the Web.config of your website! (See above)
• cd_core.log of your OData website. If this file is (almost) empty that means that the ‘Update Preview’ request NEVER reached the OData webservice. This could be due to:
  - Network issues: are the IIS Bindings of the OData webservice correct?
  - Can you connect to the OData webservice using your browser?
  - Is your publication target pointing to the correct Content Delivery Endpoint Url (your OData webservice)?
• If there is data in the cd_core.log of your OData webservice, check to see if there are error’s or unusual statements.
  • If you search for your adjusted content do you see it? If so, this means that your changed content is correctly send to the OData webservice. If not, that means that your staging website cannot connect to the OData webservice. Again: Check IIS settings and network settings.
• Open the Session Preview Database using SQL Server Management Studio, and open the table ‘Component Presentations’. After you hit ‘Update Preview’, you SHOULD see something added to this table. If not: check if you referenced the correct Session Preview Broker Database in BOTH of your Wrappers. (In the cd_storage_conf.xml of your Website and in the cd_storage_conf.xml of your OData webservice!)

If you see an HTTP error 400 BAD REQUEST after you click on ‘Update Preview’ check the following:

• Open the Windows EventLog ‘Tridion Content Manager’ on the Content Manager server and check if you see the same error here.

If so, try the following:

Stop the TcmServiceHost windows service on the Content Manager Server. (Be careful, The SDL Tridion Content Manager stops working now!)
Next, browse to the SDL Tridion install directory\bin with the command prompt and start the TcmServiceHost.exe with the -debug command. Like this:

TcmServiceHost.exe -debug

Now, open Fiddler on the Content Manager server, apply a filter to show only traffic from the TcmServiceHost and hit ‘Update Preview’ again. Now you have the request and you can inspect it to see if there’s anything unusual. E.g. the Content-Lenght is 0. That’s weird, because that means no data was send!

The last resort consist of tracing everything related to the OData webservice. If everything above failed, do the following:

Open the Web.config of the OData webservice and add the following code:

<system.diagnostics>
    <trace autoflush="true" />
    <sources>
      <source name="System.ServiceModel" switchValue="All">
        <listeners>
          <add name="TraceListeners" type="System.Diagnostics.XmlWriterTraceListener" initializeData="C:\Temp\trace.svclog" />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>

Adjust the ‘initializeData’ path to a path of your choosing.

Now, hit ‘Update Preview’ again, and after it’s finished, open the trace by double-clicking on it. (If you don’t have the tracetool, download it here)

Find he first red colored entry, and inspect the error message. In my case the ‘maxReceivedMessageSize’ of the OData webservice was too small.

You can adjust this setting in the Web.config of the OData webservice. Here is an example of the updated part of the Web.config:

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="True" />
    <behaviors>
      <endpointBehaviors>
        <behavior name="webHttp" >
          <webHttp/>
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <services>
	  <!-- HTTP support. In case of HTTPS these services have to be commented. -->	
      <service name="Tridion.ContentDelivery.Webservice.ODataService">
        <endpoint  behaviorConfiguration="webHttp" binding="webHttpBinding" bindingConfiguration="AdustedBindingConfiguration" contract="Tridion.ContentDelivery.Webservice.IODataService" />
      </service>
      <service name="Tridion.ContentDelivery.Webservice.LinkingService">
        <endpoint behaviorConfiguration="webHttp" binding="webHttpBinding" contract="Tridion.ContentDelivery.Webservice.Ilinking" />
      </service>
	  <service name="Tridion.ContentDelivery.Webservice.AccessTokenService">
		<endpoint behaviorConfiguration="webHttp" binding="webHttpBinding" contract="Tridion.ContentDelivery.Webservice.IOAuth2AccessToken" />
	  </service>
    </services>
	<!-- In case of HTTPS support uncomment this block.
	-->
	<bindings>     	  
		<webHttpBinding>      
			<binding name="AdustedBindingConfiguration" maxReceivedMessageSize="2097152000" maxBufferSize="2097152000">
				<readerQuotas maxArrayLength="81920" maxBytesPerRead="5120" maxDepth="32" maxNameTableCharCount="81920" maxStringContentLength="2097152" />
			</binding>
	    </webHttpBinding>
    </bindings>
	
	
  </system.serviceModel>

Note that ‘maxReceivedMessageSize’ and ‘maxBufferSize’ should be the same!

Don’t forget to remove this settings once you resolved all your issues!

Phew! I *really* hope your Session Preview service is now working properly.
If this isn’t the case consider asking it on StackOverflow (and while you’re there, consider committing to the SDL Tridion Exchange Proposal)
The community is really helpful and very knowledgeable. Of course you can also open a support ticket with Customer Support.

Have fun!

In a website build with DD4T (almost) all content comes from the Broker Database. The content is stored as an XML string in the database and is transformed (de-serialized) into .NET objects at request time. As you can image this has a huge impact on the performance of your website: on every request the XML is loaded (streamed) from the database and the DD4T framework de-serializes this into usable .NET objects.
This is a time-consuming process and puts a heavy load on your webserver.

Luckily there are a few options/strategies to improve the performance of your website. And the beauty about these options is that they (almost) come for free!

Output Caching

The first option is the out-of-the-box Output caching from ASP.NET.
Just decorate your controller (PageController, ComponentController; your choice) with the OutputCache attribute and your done!

[OutputCache(CacheProfile = "ControllerCache")]
public override System.Web.Mvc.ActionResult Page(string pageId)
{
...
}

And in your web.config you configure the duration of your ControllerCache:

<caching>
<outputCacheSettings>
<outputCacheProfiles>
<add name="ControllerCache" duration="3600" varyByParam="*"/>
</outputCacheProfiles>
</outputCacheSettings>
</caching>

OutputCache caches the output (…) for the duration you configured in the web.config. If the cache duration is set to 5 minutes, and in these 5 minutes you publish a page, the changes are NOT reflected in your browser if you hit F5. Only after 5 minutes the cache is invalided and on the next request the XML is loaded from the Broker Database. And de-serialized.

DD4T Caching

Luckily for us DD4T ships with a build in cache mechanism. This caching-mechanism is build on top of the .NET System Runtime Cache and can be used in conjunction with the Output Cache.

DD4T caching stores de-serialized objects like Components and Pages in the .NET Runtime cache after they are requested for the first time. Every consecutive request for that page/component loads it from the Object cache instead of loading it from the Broker database and de-serializing it into a .NET objects.
As you can imagine, this causes a massive performance improvement.

But how does DD4T ‘know’ when to invalidate the item in the cache? Because if you re-publish a page or component, you want your website to show the updated page/component.
The fact is that DD4T never knows when an item is republished, unless it ‘asks’ SDL Tridion for it. (Due to the fact that a website is stateless)
Well, this ‘asking’ is implemented in DD4T.

DD4T poll’s every x seconds/minutes/hours/etc (configurable) if the LastPublishDate from an item in the cache has changed. If it has changed (the item was republished) it will invalidate this item. The next time this item is requested, it will be loaded from the Broker databases, de-serialized and stored in the cache.

To configure how often DD4T needs to check the LastPublishDate of the items in the cache, use this setting in your web.config (value must be in seconds)

 <add key="CacheSettings_CallBackInterval" value="30"/>

In this example, DD4T poll’s the Broker Database every 30 seconds to check if the items in the cache are still valid.

Also, after a configurable amount of time, the item is -no matter what- invalidated. The amount of time can be configured separately for pages and components.
Use the following configuration settings to accomplish this:

<add key="DD4T.CacheSettings.Page" value="3600"/>
<add key="DD4T.CacheSettings.Component" value="3600"/>

In this example all the pages and components in the cache are invalidated after 1 hour.

SDL Tridion Object cache

SDL Tridion comes with a caching solution called ‘Object cache’. To quote the documentation, this is what it does:

To improve the performance of your Web site, you can choose to store the most commonly used or resource-intensive objects from your Content Data Store in a cache. The cache keeps these objects available for the applications that request them, rather than reinitializing them each time they are requested.

Pretty obvious right? So no need to explain it further.
Read the documentation here. (Login required)

More information about the SDL Tridion Object cache:

• What is the SDL Tridion Object cache
• Analyzing the SDL Tridion Object cache

Finale notes

As we have discussed, there are 3 caching options available out of the box. Used them when needed, and tweak them according to your needs.

A very nice post about caching (and the performance you gain) with a SDL Tridion driven website was written by Nuno Linhares. Read it here: Tridion Content Delivery and Caching

I hope I gave you some information about caching in a dynamic (DD4T driven) website on top of SDL Tridion to get you started.

It took precisely 3 minutes and I had my answer. Since I could not find it, I assume you also cannot find it. That’s why I share it here.
But not without mentioning the one who gave me the answer: Frank. Thanks.

For adding a JavaScript to extend the Tridion Content Manager GUI, but without showing a button or list or whatever, the following configuration is needed:

1. Add the following configuration to your ‘Editor.config’ (config file to configure your GUI Extension):

<cfg:groups>
<cfg:group name="MyGroupName">
<cfg:domainmodel name="MyName">
<cfg:fileset>
<cfg:file type="script" id="MyId">/Relative/Path/MyJavaScript.js</cfg:file>
</cfg:fileset>
<cfg:services />
</cfg:domainmodel>
</cfg:group>
</cfg:groups>

This piece of configuration makes sure that your javascript file is loaded for the complete GUI. This might not be what you want.
Let’s say you only want to load your methods/classes for a certain view, let say the Component-edit screen. You can achieve this by adding the following code to your
JavaScript file:

//If you only want your code to affect certain screens/views, you should listen to Anguilla events like this:
$evt.addEventHandler($display, "start", onDisplayStarted);

// This callback is called when any view has finished loading
function onDisplayStarted() {

    $evt.removeEventHandler($display, "start", onDisplayStarted);

    if ($display.getView().getId() == "ComponentView") {
            //Work your magic!
       }
}

It’s easy once you know how

In my previous example, the whole HTML of the (Tridion)page was rendered by only 1 (razor)view. This is not a desired scenario, because it leads to big views and re-use is almost impossible.
Tridion handles this quite nicely by using Component Templates. These templates are responsible for rendering their own little piece of content. And this is exactly what you want in your webapplication.

So, how to implement this using the DD4T framework? Lets find out by creating a simple page.

First, create a page in Tridion with 2 (or more) ComponentPresentations and publish the page. (Make sure your Component Templates are DD4T templates and have a metadatafield called ‘view’ with the name of an existing view in it!. See my previous post on how to create a DD4T Component/Page Template)

DD4T needs to know which (default) Controller to use. This needs to be configured in your Web.config. Add the following 2 lines of code in your Web.config:

    <!-- Config values for the DefaultComponentPresentationRenderer-->
<add key="Controller" value="TridionComponent"/>
<add key="Action" value="Component"/>


Next, we have to write some code to handle the rendering of the ComponentPresentations.
1. Create a new controller and name it ‘TridionComponentController’.
2. Add the following code in this controller:

using System.Web.Mvc;
using DD4T.Mvc.Controllers;
using DD4T.ContentModel;

namespace Sample_WebApplication.Controllers
{
    public class TridionComponentController : TridionControllerBase
    {

        public ActionResult Component(ComponentPresentation componentPresentation)
        {
            return base.ComponentPresentation(componentPresentation.Component.Id);
        }
    }
}

This controller is used to render each ComponentPresentation on a page. The TridionControllerBase class reads the metadata from each ComponentPresentation to find out which razorview to use. The result of the Action-method is a rendered componentpresentation.

Now, create a folder ‘TridionComponent’ in the ‘Views’ folder, and create a new razoriew. Give this view the same name as you defined in the metadata of your ComponentTemplate. So, in my case that is ‘Article’.
Add your HTML to this new View. My Article view looks like this:

@using DD4T.ContentModel;
@using DD4T.Mvc.Html;
@model IComponentPresentation

Component title: @Model.Component.Title

<h1>@Model.Component.Fields["title"].Value</h1>
<p>@Html.Raw(Model.Component.Fields["summary"].Value)</p>
<p>
    @Html.Raw(Model.Component.Fields["body"].Value)
</p>

Now we have to adjust our main view to NOT render the ComponentPresentations inline, but to use our new controller and the DD4T ‘ComponentPresentation’ Action method.
Open your Page view (In the folder TridionPage, General.cshtml) and add the following code:

@using DD4T.ContentModel;
@using DD4T.Mvc.Html;
@model IPage

<html>
<head>
<title>@Model.Title</title>
</head>
<body>
<p>
Some info about this page:<br />
Filename: @Model.Filename<br />
Title: @Model.Title<br />
Publication Title: @Model.Publication.Title<br />
</p>

<h2>ComponentPresentations on this page</h2>
@Html.RenderComponentPresentations()
</body>
</html>

Notice the @Html.RenderComponentPresentations()? This is a HTML helper from the DD4T framework that renders all the componentpresentations on the page, using our newly created ‘TridionComponentController’.

This ‘RenderComponentPresentation’ HTML helper renders ALL the ComponentPresentations, but often you only want to render certain ComponentPresentations. For instance, you want to render ‘Banner’ components in another section on your page then your ‘Article’ elements.
This can be achieved by using one of the overloads from the ‘RenderComponentPresentations’ HTML helper.

To only render ComponentPresentations that are based on a certain schema, you can use this code:

@Html.RenderComponentPresentationsBySchema("ArticleSchema")

To render ComponentPresentations based on a certain ComponentTemlate, you can use this code:

 @Html.RenderComponentPresentationsByView("Article")

Or, if you want to render ComponentPresentations based on multiple ComponentTemplates, you can use this code:

 @Html.RenderComponentPresentationsByView(new[] {"Article", "FullArticle" })

I hope this helped you to understand how ComponentPresentations are handled by the DD4T .NET framework.
Let me know if you have more questions or problems using the above code.

In this post I am going to explain how to set up and use the Dynamic Delivery For Tridion Framework. If you haven’t heared of this framework check out this site: http://code.google.com/p/dynamic-delivery-4-tridion/
In short: Dynamic Delivery For Tridion (DD4T) is an ASP.NET MVC3 framework specifically designed to build a web(site) application using SDL Tridion.

Prerequisites:
1. Visual Studio 2010 (With Entity Framework 4.1 installed and MVC3)
2. SDL Tridion 2011 Content Management Server
3. SDL Tridion 2011 Content Delivery Instance
(The DD4T Framework also supports SDL Tridion 2009. But in this post I use SDL Tridion 2011)

Also make sure that you are publishing everything to the Tridion Broker Database. (You can configure this in the cd_storage_conf.xml)

High level overview

For a highlevel overview of the framework, check out this url: http://prezi.com/tzxk2w9ic284/developing-with-aspnet-mvc-and-tridion/

To get your website up and running using the DD4T framework, the following steps are needed:

1. Upload the Dynamic Delivery Template Building Blocks to your Content Management Server
2. Create Component Templates and Page Templates using the Dynamic Delivery Template Building Blocks
3. Create a webapplication that uses the DD4T DLL’s to show your published page

Getting started

Download the sources from code.google.com
(Use a SVN Client like TortoiseSvn in combination with a Visual Studio plugin like AnkhSvn)

The sources contain the Java version and the .NET MVC3 version of the project. We are only interested in the .NET MVC3 version of the framework.

Template Building Blocks

First, we have to upload the Template Building Blocks to the Tridion Content Management Server.
Check out this WIKI page on how to upload the templates

Component Templates and Page Templates

Once you uploaded the Template Building Blocks, you can use these to create Page- and Component Templates. To create a Component Template, open up the Templatebuilder tool and create a new Component Template. Drag and drop the following (DD4T) Building Blocks on your template:

• Generate dynamic component
• Publish binaries for component

Also, create a Page Template with the following (DD4T) Building Blocks:

• Generate dynamic page
• Publish binaries for page

Next, create a simple meta-data schema with one single line text (Preferably it’s a selectlist with values from a category) for usage on the newly created Component- and Page Template.
This schema allows you to tell the DD4T framework which View (visual representation, ASP.NET MVC3 Razor template) to use when this Page/Component is rendered in the browser.
Xml name of the field should be ‘view’.

Component Template for Articles, using the View ‘Article’:

Do the same for the Page Template: Give it a metadata-schema, with one field called ‘view’ and insert which view to use in the framework:

Visual Studio Projects setup

Open up Visual Studio and create new project of type ‘ASP.NET MVC3 Web Application’ (Make sure you are using the Razor view engine)

Next, we are going to add some projects (dll’s) from the just downloaded DD4T framework. Choose from the ‘File’ menu for ‘Add’ -> ‘Existing Project’. Add the following DD4T projects to your solution:

• DD4T.ContentModel
• DD4T.ContentModel.Contracts
• DD4T.Factories
• DD4T.Mvc
• DD4T.Providers.SDLTridion2011 (Or DD4T.Providers.SDLTridion2009 if you are using SDL Tridion 2009)

Your solution looks something like this:

Remark: in a real life application you don’t want hard references to all these dlls. You want to load the dependencies by means of Dependency Injection (Unity, MEF, etc)
Next, we have to copy some Tridion dll’s into the following folder: %DD4T Install Path%\dependencies\Tridion 2011 DLLs. In here you find a file called ‘Missing files’. Read it, and copy-paste all the Tridion Dll’s into this folder.
Now, add all the DD4T projects as a reference to your MvcApplication. Your solution should build fine now.

The DD4T framework uses the web.config to find out from which publication to request content. Add the following 2 keys to the web.config. (Of course, fill in your publication id)

<add key="Site.ActiveWebsite" value="Corporate.En"/>
<add key="WebSite.Corporate.En.PublicationId" value="7"/>


Writing *some* code

Now we have added all the necessary framework parts, it’s time to wire up our first controller so we can view our page in the browser. Luckily for us, the DD4T framework has already done a lot for us. Al we have to do is to use the right methods and classes!
If you aren’t familiar with the .NET MVC pattern, this is roughly how it looks like:

1. Url is typed into the browser
2. Request is fired to the webserver and our webapplication. It goes through a ‘rout-engine’ (Global.asax) to find out what to do with this url (request)
3. This route-engine looks at the url and based on the parts of the url it sends it to a controller
4. The controller builds up the Model and passes this model on to the View
5. The (razor)View renders the HTML and pushes the output back to the browser

First step is adding a rule to the Global.asax that makes sure that (for now) all requests are handled by the same controller. Add the following code to the ‘RegisterRoutes’ method from the Global.asax:

routes.MapRoute(
               "TridionPage", // Route name
               "{*PageId}",
               new { controller = "TridionPage", action = "Page" }, //Parameter defaults
               new { pageId = @"^(.*)?$" } //Parameter constraints
           );

This makes sure that every request is passed on to the TridionPageController.

Time to make the TridionPageController! Go to your MvcApplication and create a new controller. Right click on the ‘Controller’ folder in the solution explorer and choose ‘Add’-> ‘Controller’.
Name it: TridionPageController

By default all controllers from ASP.NET MVC inherit from the Microsoft Controller class. We don’t want this. We want to inherit from the TridionControllerBase class from the DD4T.Mvc project.
Make sure your TridionPageController inherits from the TridionControllerBase:

public class TridionPageController : TridionControllerBase
{
        public TridionPageController()
        {
            this.PageFactory = new DD4T.Factories.PageFactory();
            this.PageFactory.PageProvider = new DD4T.Providers.SDLTridion2011.TridionPageProvider();
        }
}

Remark about the above code: The factories and providers are created here for simplicity. In a real world scenario you don’t want to do this, but you want to load the Factories and Providers by means of Dependency Injection (Unity, MEF, etc). But for now it’s ok.

The TridionControllerBase defines a set of useful methods. We want our controller to look up the page (url) we requested in the browser from the Tridion Broker Database. Normally you would write code, using the Tridion dll’s to retrieve the Pagecontent from the Tridion Broker Database yourself, but the DD4T framework has already done this for us.

Add the following code to the TridionPageController:

public override ActionResult Page(string pageId)
{
    return base.Page(pageId);
}

This method retrieves the PageContent from the Tridion Broker Database by finding the Page by it’s Url (pageId = Url). So, make sure you published a page to the Tridion Broker Database using the DD4T Templates!

The View

The ‘Page’ method returns *something*, but we have to define of course how that ‘something’ needs to be visualed. In other words: we need to create a (razor) view.
ASP.NET MVC3 uses a pattern to find the right View to visualize this page and it uses (among others) the name of the Controller to find the view. So, in the ‘Views’ folder, create a new folder
‘TridionPage’. In here we have to define the View. Remeber the metadata schema we made for Component- and Page Templates? Well, your Pagetemplate has this metadata on it, and you gave it a meaningfull name. I named mine ‘General’. So I have to create a view named ‘General’. Here is how my folder structure looks like:

Views contain the HTML. Here we define how our page looks like. One of the advantages of the DD4T Framwork is, that you can have strongly typed views. This means that you tell your View that he (she) needs to render HTML for object of type IPage or IComponent or String (not very usefull) or MyArticleObject, etc. This gives you full intellisense when writing your View.

Your view needs to render the HTML for an IPage object. (IPage object comes from the DD4T Framework).
Add the following code to your view:

@using DD4T.ContentModel;
@model IPage</pre>
<h2>@Model.Title</h2>
<pre>
    Some info about this page:

    Filename: @Model.Filename

    Title: @Model.Title

    Publication Title: @Model.Publication.Title

Component presentations on this page:</pre>
<ul>
<ul>@{</ul>
</ul>
&nbsp;
<ul>
<ul>foreach (IComponentPresentation cp in Model.ComponentPresentations)</ul>
</ul>
&nbsp;
<ul>
<ul>{</ul>
</ul>
&nbsp;
<ul>
<ul>
	<li>@cp.Component.Fields["title"].Value</li>
</ul>
</ul>
&nbsp;
<ul>
<ul>}</ul>
</ul>
&nbsp;
<ul>}</ul>
<pre>

ASP.NET automatically wires up the properties from the IPage to the ‘Model’ keyword because we told this View that he (she) is destined to render HTML for an IPage object. (The ‘@model IPage’ directive).

And now: RUN! (F5)
Make sure you are requesting an Url that is published to the Tridion Broker Database

I hope this gives you enough information to get started with the DD4T Framework. The framework is actively developed and it is already running live in at least one big financial organisation.
So far everything runs just fine

Disclaimer:This example is provided as is and is simplified for the obvious reasons.

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

• Kah Tang (http://kahwah.me/)
• Alfred Creemers (.NET Developer)
• SDL Tridion
• Me

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.

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)

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.

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.

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.