Recently a client required a way of creating and storing ‘dynamic’ values within the content managed in SDL Tridion. Â By ‘dynamic’, this could be anything from loan rates, petrol prices or the cost of a pint of beer. Â So today ‘pint_beer_cost’ could be $3.50, tomorrow it could be $4.50. Â Having to go through all stored content and replace $3.50 with $4.50, every time there is a need to change a value would be quite painful.
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.
Continue reading
When you open up the SDL Tridion UI for the first time you are directed to the SDL Tridion tab which shows you a welcome screen, this is sometimes also referred to as the SDL Tridion dashboard. If you open the Experience Manager view, you actually see that the first tab is called “Dashboard”. This dashboard contains useful information for an editor and is even extensible, allowing for a rich user experience on your extensions. Typical things are settings for your own extensions, or perhaps user specific pages (like a custom page, but then tailored to the logged in user) since you have all the UI capabilities available here.
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.
As a good developer, you write out useful information and debug messages in your .NET TBBs using the built in templating logger. This is great when running the TBBs in the template builder to give a bit of extra info about the processing. However, by default info messages will be logged in the Tridion Event Log of your Publisher server, causing log bloat, and making it harder to see important Error and Warning messages. Its really easy to turn this off, but I am not sure I have seen it documented anywhere. Heres how…
I’m seeing challenges and confusion with BluePrinting and Targeting in BluePrint workshops and in discussions about profiling and personalization. Don’t let the rise of “Customer Experience Management” (CXM or CEM for TLA fans) adversely affect your SDL Tridion BluePrint. Localization != Personalization (!= is code, literally, for “not equals”).
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
Recently I had a customer ask me for a rather simple feature – the ability to have Tridion folders and structure groups inherit the metadata schema and values from their parent. This would be only when creating new organizational items and obviously we want to show these default values on screen when editing.
Having spent the past few months completely buried in Anguilla/CME extensions, I obviously started thinking of implementing this by extending a whole bunch of Anguilla Commands and going all crazy on Javascript.
The word complex in English means the exact same thing as it does in Dutch, although the Dutch dictionary simply puts it as: “compound, complicated” where in the English dictionary I at least find “composed of many interconnected parts” as a first description and the words complicated and hard to understand are following much later.
Back in February I posted an article about Custom Resolvers. Yesterday I rolled my first Custom Resolver into a production environment, so I figured it was time to share my findings.
To set the scene, it probably helps to explain the business requirements first. We have a large implementation with over 300 publications. Many of these share content, some of which needs to be secured, and links to binaries that also need to be secured. We have a third party security solution, which is implemented as a proxy on top of our published site. The proxy looks for a security.xml in the folder of any request, and then prompts for login etc depending what is contained in the XML file. This works very well for pages, but the pages often link to binaries (which were all contained in the “/images†directory for each publication). In order to secure binaries with different sets of restrictions we needed to bind the binaries in different Structure Groups. To simplify the concept, we decided to publish a variant of each binary linked from a page to the same Structure Group as the page. This has the desired effect of securing all binaries that are linked from secured pages with the same restrictions. When a binary is linked from multiple secured pages, multiple variants of the binary are published. Continue reading