Client Templating For Tridion – Part I

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?

CT4T

And that’s where CT4T comes into the picture. It’s a set of tools and API’s to easily add client side templating to your projects. The best part is, because its just JavaScript, its flexible enough to allow you to mix and match the different publishing models to meet your project needs. You can continue using your DD4T or CWA project if you wish to and just augment it with some client side goodness. Or you can mix a bit of old fashioned static pages published from Tridion with client side templating. Or you could be daring and create a completely new single page web application. The choices are yours.

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.

Join Us!

Super Charge Your JavaScript Development With TypeScript

Though my current writings on this blog may not show it, I’m more than just a Tridion and .NET nerd. Don’t get me wrong, I’m a huge .NET fan. But I love other technologies as well… one of them being JavaScript. Sure JavaScript may have gotten a bad rep as being a slow, crappy client side scripting language. And due to its heavy use in browsers, a lot of JavaScript development is done by non-programmers who don’t know any better, so a lot of what you see out there could have been done poorly in pretty much any language if done by the same group. But underneath the hood when you dive into its capabilities, there lies something beautiful (and not so slow when tuned correctly!). And I truly believe that there also lies the future of web technologies.

I’ve been working heavily with NodeJS in a couple of my side projects. For those who have not heard of this, NodeJS is a server side JavaScript technology. Now this is where I may get some eye rolls from fellow colleagues… JavaScript on the server? Now that’s gotta be buggy and slow, right? And at one point in my life (probably just a little over a year ago), I would have full heatedly agreed that the server was no place for some error prone JavaScript. But after much investigation into Node (and thus into JavaScript as well), I was in for such a surprise. A pleasant one.

Even with the new found love and understanding for this misunderstood technology, there was still something missing in my JavaScript project. Now I’m not talking about a project of a few hundred lines of code or less. I’m talking about one that has expanded into thousands. And the maintainability, especially for someone who has grown use to his conveniences of the tools in Visual Studio, was slowly becoming a nightmare.

And then recently, a colleague of mine introduced me to TypeScript, a “typed superset of JavaScript that compiles to plain JavaScript”. Yep, we’re talking about strongly typed JavaScript, classes, interfaces, and even some ES6 future features. The best part is, unlike some of those other languages that compile into JavaScript, TypeScript IS JavaScript. You can copy paste existing JavaScript code into your TypeScript file, and it’ll work. The best part is, with Visual Studio 2012 (and the plugin), you now have full intellisense support with your TypeScript JS, refactoring, and even code lookup (yep, that’s right, F12 it).

So, those maintainability issues that I was having? Yep, you guessed it… I’m currently in the process of re-writing my code into TypeScript style classes (not so much trouble since I was already using classes in JavaScript, function style). I’ll probably write up some posts on things that I’ve learned, probably maybe even an example of a GUI Extension with it as well. In the meantime, if you’re someone who’s writing some pretty complex JavaScript applications (client or server), I’d definitely recommend giving it a try. It’s not perfect yet, bit it has rekindled the fun in my JavaScript projects.