SDL Tridion CMS in a mess? Get yourself one of these:
I’ve provided a little summary after the jump, but really you should be clicking the link above and watching this first major presentation for SDL Tridion 2013. Thanks to all involved in the webinar
I was fortunate to have a preview version the up and coming 2013 release of SDL Tridion to play with. One new feature is Bundles, which is basically a new type of organizational item, which allows you to group together related items, and do operations on them as a whole. Typically this would be putting it through workflow, or publishing them all together in a single transaction, but one nice thing about them is that you can use them however you want to, just add items into a bundle, and use it however you need to.
The new release of Content Porter will also be bundle-aware, which got me thinking that there should be an easy way to keep track of changed items during development using bundles to avoid the pain of keeping track manually. It turns out to be really easy using the Event System.
Looking for the SDL Tridion PowerTools
A piece of advise that I learned from a wise Tridion sensei is that it’s not a good practice to localize pages in Tridion if you have a multi-lingual site (though there is an exception to this rule which I’ll discuss below). The reason for this is simple: you lose the ability to centrally manage your site from the Master web publication. Once a page is localized, you have to manage it individually, which is not ideal if you want to centrally update component presentations on a page across all the language sites. So what do you do if you want to obey the rule of not localizing pages and your customer asks to have localized/translated URLs?
To provide context between similarly-looking SDL Tridion environments, consider Skinning the Content Manager Explorer as described on SDL Live Content.
Simplified, slightly modified, and with some pics. This is a fairly quick and easy way to make your CMS environments stand out from each other. For the full power of CME Themes, head on over to YATB.
I’ve recently helped a client resolve some interesting issues with their Tridion template building blocks. The issue was that when publishing the first time desired results were produced by the template. However, when publishing many pages, or republishing the same page/component presentation, subsequently produced strange output results.
The logic in our TBB parsed the Output item in the package and made various manipulations to it. I won’t get into the details of that. The issue was due to having static private variables declared within the TBB. These variables were various data structures and primitives manipulated by methods within our ITemplate-inherited class. The methods themselves had to also be declared as static. Refactoring the code away from “static” resolved the issue.
Here is why you cannot use static variables in Tridion templates: Primarily because they become global shared variables across all publish threads. Here is what the Tridion TOM.NET Session and Engine class API states regarding this matter:
IMPORTANT NOTE: Session objects are not thread-safe; you must not share Session objects across threads. Furthermore, the thread that creates a Session object should be in a Single Threaded Apartment (STA), since the Session will internally create an Apartment Threaded COM object. See SetApartmentState(ApartmentState).
The Tridion Session object, which the Engine uses (or, as the docs put it, “aggregates”) subscribes to the Single Threaded Apartment model (STA).
An STA is basically a model where the server controls the threads, and each individual thread must not spin off additional sub-threads that depend on the STA-controlled objects. So in our case: the Tridion CM is the server that spins off and controls threads (e.g. we can publish many items simultaneously), and each template is executed within it’s own thread. So if we develop a template that spins of other threads, the common memory across threads, i.e. static variables, isn’t managed. So STA threads can overwrite each other.
Here is a snippet from an article explaining STAs in much more detail:
…all access to global variables and functions of the server will need to be serialized properly because more than one object may try to access these from different threads. This rule also applies to class static variables and functions. [http://www.codeproject.com/Articles/9190/Understanding-The-COM-Single-Threaded-Apartment-Pa]
So in a common scenario, when is it appropriate to use “static” within a TBB? Well, how about in procedural methods that take some inputs, create new objects, massage them and return them. In other words, if the method is self-contained. A Utility class is a common such scenario.
In conclusion, don’t use static variables inside your TBBs or Event System code.
Most implementations I have worked on have sections of the website which consist of some kind of listing, which links through to pages containing detailed content. The details pages themselves contain a single ‘Full Article’ component presentation, and are often auto-created and published using the event system. As such, the pages do not really serve any purpose other than providing a definition of the url for an article.
This article shows an alternative approach to get rid of pages for a certain section of your site and use the features of ASP.NET MVC to show content without losing ‘real’ urls