Figuring out what methods to implement when extending the Storage Layer

If you want to do something around Storage Layer extensions, we already have some nice examples in Tridion World. One example explains how to extend the file system storage factory for a CDN use case. Another example shows how to implement storage for a new item type.

I would like to add some extra information that may clarify a couple of concepts around the methods that have to be implemented depending on the storage extension need.

Creating a new Item Type

When creating a new Item Type, new DAO, you can define any method you want. Our framework has no restrictions there.

Extending an existing Item Type

When extending an existing Item Type, the methods to implement need to conform to a contract, that means the DAO interface.

This information is very relevant for customers who want to upgrade a Deployer extension in SDL Tridion 2009 to a Storage Layer extension in SDL Tridion 2011

With 2011, R&D created the new DAO interfaces and they tried to make them resemble the old Home classes as much as possible.

There are exceptions to this though, for instance, ItemDAO. For the ItemDAO, they tried to unify four old home classes (the meta ones) into one DAO. As an effect of that, while in 2009 we would be implementing update and insert methods, in 2011 those two actions are gathered into one method, store.

To be sure, check doc doc doc

As a final note, when you need to work on extending the storage layer, do not forget, as a first step, to check the SDL Tridion 2011 Content Delivery JSP API documentation. There you will be able to see the methods to implement, etc.

Using Outbound E-mail but managing contacts from an external system

Outbound E-mail (and Audience Manager)

Since the first time I "met" TMCS, I must say I have been quite fond of it. With 2009, "he" changed his name into Outbound E-mail, which definitely helped to clarify what it was all about! Outbound E-mail (and Audience Manager) were now integrated in the SDL Tridion GUI! And some new capabilities were also added.

I really like the business strategy behind using Outbound E-mail. The Web channel is definitely important when engaging users, but we should not forget how powerful the e-mail channel still is these days. For instance, a lot of promotions are greatly successful because existing or potential customers are approach via e-mail. And not only can they target their customers but also measure their (clicking) actions on the email, etc.

Just a little note on the relation between Outbound E-mail and Audience Manager. Quite often, we talk about Outbound E-mail implying the use of Audience Manager too. They are two separate modules, but work together to bring the e-mails and e-mail campaigns to the customers. End users experience work with both modules transparently, as if it was one. For further clarification, read below a line by SDL live documentation on their scope:

Audience Manager enables marketing departments to gather information about audiences, such as interests and characteristics. Outbound E-mail is for marketing departments that need to implement and manage e-mail communication campaigns.

Having said that, let me get back to my original goal here, write about my experiences with OE (I will use the acronym from now on). First round of OE coming!!!

A toast

Where is Wally/Waldo? Imagine I impersonate Wally for a moment... Then Wally is in China!

My trip to China last Saturday was... to say the least... very long. 24 hours. I had two or three delays, 12hours in total; I encountered the huge language barrier, had to ask the same question around "1000" times... etc, etc.

I want to speak from here to all the Wally's in Professional Services SDL WCMS (Tridion! ;)). I want to propose a toast to all of you, us, travellers, consultants.

(Did you already take your drink? :D)

Because being a Wally can be exciting and beautiful! But it can also come with a lot of inconveniences. To all of you, because you do a great job and you keep on smiling! What else can we ask for? Oh yeah... the drink!!!!

Cheeers!!!!!!!!! 

Manipulating (embedded!) fields from a Custom URL resource

As of SDL Tridion 2011, we have a new API for manipulating fields within Web resources referenced by Custom URLs. You can find some basic examples on live documentation.

I got a question by a customer on how exactly to deal with embedded fields. I played around a little bit with it and I thought… let‘s share the result!  :) It is actually pretty simple, we deal with embedded fields in the same way as we do for the rest of fields.

My use case

Custom URL associated to field Paragraphs:

·         Embedded schema Field, that contains two inner fields

o   Heading

o   Text

·         Multivalue

When we click on the Paragraphs field description, we will set default values to both heading and text as an example. This is the expected result:

Keeping HTML design separated from code

The well-known part

Since Tridion 5.3 was born, we dived into Modular Templating. If you have seen our trainings on Modular Templating or if you have just read about best practices on this field, you'll probably know that we emphasize on the fact that modules should be built in a way that code and design are well separated. So if you are using Dreamweaver (DW) and .NET Template Building Blocks (TBB's), the DW should be kept simple and contain the HTML output while most logic should go into your C# code. This best practice keeps your templates neater and as a result more maintainable. For instance, if there is a simple change in the graphical design, only the DW modules will be affected; the C# code will stay untouched and there won’t be a need for recompiling it.

Okay, the first part of my story is clear. Let me step into my second point. There is one important consideration to make – what about those pieces of a website that involve some dynamism?

Where it can go wrong

In a lot of cases, the full html (or I could call it “the full puzzle”) cannot be generated at publishing time. We are then talking about front end functionality that will get executed at request time.

Examples of this dynamic functionality are the following: 

1. Reading from generated xml files – i.e. Applications.xml
2. Retrieving data from external sources – i.e. retrieving data from a product catalog.
3. Language selector – i.e. display the languages where that page is available at the moment of request.

The result of the example functionalities from above could be:

1. Data coming from the xml displayed as foldable headers and tables where every row represents an application version which is still supported.
2. A price of a product retrieved from a product catalog
3. A list of clickable languages using a specific html. The current language is selected in the list. There are no broken links nor empty items in the list.

Let me take a moment to get back to the initial part of my story:

We know that when creating Modular Templates, it is important to separate html output (DW) from complex logic (C# code). That is to say, we are trying to make our code independent from the HTML design. Great, but then, shouldn’t we do the same with the code we write for the web application?

The answer to this is clear: Yes! As much as possible! And this article gives you ideas on how to do it.

Entre dos aguas

I was born Entre dos aguas.

Do you know the beautiful guitar song with that name by Paco de Lucía? If you like flamenco music, you will enjoy his; he is a master with the guitar. "Entre dos aguas" is one of his most famous songs. He comes from my city, the city right between mediterranean sea and atlantic ocean, Algeciras.The song title is therefore refering to Algeciras, literally "between two waters".

And I left my land between two "waters" to see other lands... and other oceans and seas. I am travelling a lot for work these days... I am more than ever, anywhere and nowhere at a time.