As mentioned in my previous post, the MVP’s actually got down to grind out some work and code during the MVP Retreat. Nuno gives a nice overview of the open source projects in his post. I joined the Client Side Templating team, which was led by Will Price and also included Angel Puntero and Mihai Cădariu. The following post(s) will give some context to the details of that project.
Just show me the code…
If you don’t want to be bored by reading and just want to check out the project itself, feel free to check out the project site’s wiki pages and code.
Current Templating Models
Publish Time Rendering
Currently Tridion works out of the box with a templating model that gets resolved at publish time. If you have used DWT or the Razor Mediator, you have been using this such model. This is great for publishing static content, but what happens when you want to start diving into dynamic content? Sure, you can publish dynamic component presentations. With DCP’s, your presentations are still being resolved at publish time, but you can pull the content in dynamically on your pages via the Content Delivery API.
Dynamic Rendering or Request Time Rendering
Even with using the DCP’s, your development process can still end up feeling very inflexible and hacky at times. That’s where such frameworks such as CWA or DD4T come to the rescue. These awesome frameworks offer an MVC application side templating approach to your projects. Your templates actually live on the application server, and are rendered dynamically at request time. With CWA, your page views are dynamic while your component presentations are still rendered at publish time, and then your views pull the data and presentations in. With DD4T, templating is completely removed from the CMS side of things, and both the page and component views are handled by the application. These frameworks offer a much larger flexability in the way you can architect your projects, and even some added bonuses. For example, with DD4T (and using ASP.NET MVC), you can do your template development inside of Visual Studio using Razor and get the best out of the Intellisense tools. There’s no better feeling than getting drop down help and documentation as you code along with immediate errors and warnings without having to compile the project.
But Why Client Side Templating?
You’ve probably seen a lot of client side frameworks becoming extremely popular as of late. That’s because the benefits of letting the client’s browser handle some (or sometimes all) of the templating for you has numerous benefits. The number one benefit of course is the reduction costs. If you think about it, besides images and other binaries of course, the bulk of the size of your requests isn’t necessarily the data you are serving, but rather the markup itself. Most of your pages probably have the exact same markup, and only the data its relaying is different. Say if you had a 1000 Product pages. If your visitor visits each of those pages, your server has had to render the exact same markup for that page, and serve it, 1000 times, even though its pretty much the exact same page. But what if instead you only loaded the markup in the form of a template once, cache it, and for each of the 1000 pages only send your customer the raw json data needed for the page? You’ve now not only saved on bandwidth costs, you’ve saved on processing that your server would normally have to do for template rendering, and you’ve most likely decreased your web applications load time. Awesome, right?
To Be Continued…
In my next post I will discuss a bit about the architecture and decisions that were made so far. Remember, this is an open source community project, and if you feel like this is something that interests you, or better yet something that your client would love to have, I encourage you to contribute and join in. The CT4T project is still in its infancy and has a long way to go, and you have the chance to participate to create something great.