What the REL?! – A simple and very practical use of REL

SDL Tridion introduced a new target language in the 2011 release – rather mysteriously named REL. Discussions on what exactly this is for tend to very quickly get rather technical and revolve around Dynamic Rendering, developing custom tags in Java, the new Content Delivery web service and such.

An often overlooked feature (introduced in 2011 SP1) is a very simple use of REL which can be of use in a large proportion of SDL Tridion implementations, regardless of Content Delivery architecture and not requiring any custom development. In this post I will attempt to explain what this is, and why you will want to use it.

Pretty much every implementation I have worked on has had website requirements that require content snippets to be published independently from pages as Dynamic Component Presentations (DCPs). Think of Promotions or Banners which are dynamically selected and put on a page either at random, based on a query, or using targetting technology such as SDL SmartTarget:Emirates PromotionsThink of a product catalogue which can be filtered and navigated using a Taxonomy:Product Catalogue

Think of a dynamic list of News or Events which can be filtered by location or sorted by date: You get the idea.

Typically these content snippets are a teaser of content – perhaps a heading, image and summary text, which we want to link through to a full page with further details.

So far so good – we create a teaser Component Template (CT), set it to be Dynamic and write out the heading, image and summary text. Tridion Dynamic Linking is what we want to resolve the link from the teaser to the full page and this is where it gets interesting.

A CT can have different Output Formats. The relevant ones in this case would be:

  • HTML Fragment – this cannot contain any executable code, just plain HTML – no use for us if we want dynamic linking, unless we somehow write some code to post process the DCP content for links and resolve them. 
  • JSP – for a Java website this is OK, although the DCPs must be published to the filesystem and to a specific folder within the web application
  • ASCX – similar to JSP but for ASP.NET sites – again DCPs must be published to the filesystem and to a specific folder within the web application
  • REL – this is the new one in 2011, we will talk about this now

Normally when you publish a DCP your templates render linking code as TCDL (Tridion Content Delivery Language). This then gets transformed into the appropriate JSP or ASP.NET syntax by the deployer, and this code is then executed by the application server when the DCP is requested.

When you publish REL the TCDL is not transformed, it stays in the published content as TCDL. When the DCP is requested all the TCDL code is executed before the content is returned – so hey presto! my teaser link gets resolved to link through to my full page, just by requesting the DCP.

“Big deal” I hear you grumble – thats no different to publishing JSP or ASCX.

Well most of you who have had the pleasure of going live with a website making heavy use of JSP or ASCX component presentations will know otherwise. This model simply does not scale at all well for a couple of reasons:

1. JSP and ASCX DCPs need to be compiled, so the more you publish the more memory you need in your web application. No big deal when you go live with 100 DCPs perhaps, but what about in two years time when your product catalogue expands with 5 new lines, or your news archive fills with hundreds of items?

2. Worse still, ASP.NET has some behavior which actually recycles the application pool (think restarts the website) when a certain threshold number of changes are made in a particular folder. So publishing/republishing a significant number of ASCX DCPs can cause your website to restart. This can be configured away to a certain extent, but there are consequences for memory usage.

3. Both JSP and ASCX DCPs must be published to the file system into a single folder. Not the most efficient of storage mechanisms for large volumes of content.

So you might get away for it for a while, based on the original requirements and content, but we all know that things change and you may get into trouble later on and have to resort to publishing the DCPs as HTML fragments to the database, and then write a post processor to render the links (and then republish all that content!). Or… you can just use REL.

REL DCPs can be published to the file system or database, just configure your storage config accordingly and off you go. No custom coding required – it really is that simple.

Of course REL is used for a lot of other things. If you are interested to read more, you can get stuck in to Jaime’s post on Dynamic Rendering

It is worth noting that this approach requires some changes made in SDL Tridion 2011 SP1. In the GA release it was only possible to publish REL DCPs if your publication target language was set to REL (meaning, you could not, for example publish ASPX/JSP pages which use REL DCPs).

12 thoughts on “What the REL?! – A simple and very practical use of REL

  1. Nice article Will,

    Always wondered what “REL” really did!
    Are you saying then at its simplest, you can avoid the recompilation overhead by just changing to REL?

  2. Hi Will, Nice article! So, if I am right this REL target will do for instance resolve all the component links and such, but not make a dynamic file on the file system? Which is why it is different from publishing a static HTML/TXT file, right?

  3. Yes Hendrik – REL is perfect for DCPs which contain just HTML and some dynamic links. If you publish the the file system then you will see files with the .rel extension created. For large volumes I would always recommend publishing to DB however.

  4. REL is definitely one of those “wow-that-changes-what-I-knew-about-Tridion” benefits, especially for anyone who’s retrieved DCPs from a content delivery (broker) database and wonder why links weren’t resolving.

    Thanks for the clarification, Will–excellent post!

  5. Hi Will.. Thanks for the great post.
    Can you calrify me one doubt.
    If I want to add some code sections which will run at server in My page. In DWT I cannot embed any code, can I proceed with with REL or DCP. Apologies if the doubt is simpler.

    Thanks.

  6. Hi muzimil – your question is not really clear, REL is not an alternative to DCP, but rather one of the (many) output formats for DCPs. If your dynamic component presentation (DCP) contains a lot of server side code then REL is probably not the right approach. In order to execute code in REL you need to create your own custom tags in Java (see the link in the post to Jaime’s post on Dynamic Rendering), and while this is OK for simple stuff, I dont think you really want to put a lot of complex logic in here. You can use ASCX/JSP as an output format for your DCP and add inline code, or (better) your own webcontrols/taglib code to handle the server side logic, but be careful for scalability issues mentioned in the post. This approach also works if the CP is not dynamic, but embedded in your ASP.NET/JSP page.

  7. Hi Will, we have tried this by setting both the DCP and target language as REL but with no luck. The storage file is pointing to sql db. In your article you have mentioned “It is worth noting that this approach requires some changes made in SDL Tridion 2011 SP1″ , could you pls advise on what else is missing?

  8. Pingback: DD4T and SDL SmartTarget 2014 Integration | SDL Tridion Developer

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>