Translate
In this three part series, a unified way of working with Compound Templating or Modular Templating is presented. Part one starts with Dreamweaver Template Building Blocks, part two continues with C# code fragment Building Blocks, and part three finishes with .NET assembly Building Blocks.
Part 1
As an architect, I often start to think about the correct usage of a new technology and which problems can be solved with it. So I spent some time contemplating a good way to use Compound Templates.
It is easy to write a Template, but it is harder to write a Template that is understandable by other developers, maintainable (easy to change existing code?), extensible (easy to add new code?), reusable (in another project), reliable (will it continue to work if the surroundings change, e.g. a different version of SDL Tridion?).
So it is easy to fulfill the functional requirements, but it is also easy to fail on some of the "ilities" (understandability, maintainability, et-cetera) or non-functional requirements.
The Compound Templating Framework
The Compound Templating framework consists of a Compound Page Template type, a Compound Component Template type and a Template Building Block (TBB) type. The TBBs consist of the template subtypes:
- C# code fragment
- Dreamweaver template
- .NET assembly
Each of those TBB subtypes is a technology to implement a (functional) requirement in the best way and offers a design principle which is called 'separation of concerns'. It separates or divides your problem into smaller and simpler ones which can be solved easier.
The different levels of templating Level 1: Dreamweaver templates
The first level of templating is the use of only Dreamweaver TBBs to display the fields of a Component by using placeholders (an example of this is @@Component.Title@@ or ${Component.Title} ).
Level 2: C# code fragments
The second level of templating is the use of a Dreamweaver TBB with a C# code fragment to implement requirements which are not possible solely with Dreamweaver TBB.
If you need to write a few lines of code to solve the problem and if it is specific for a single project then use a C# code fragment TBB. However if the C# fragment is a generic solution which can be reused in other projects then it's better to make it a .NET assembly (with documentation on how to use it), or turn it into a Dreamweaver custom function.
Level 3: .NET assembly
The third level of templating is the use of a .NET assembly together with a Dreamweaver TBB to implement a complex solution which is hard to solve solely with a C# fragment. An example of this is a .NET assembly (DLL) that generates an XML document containing the Structure Groups for site-navigation, sitemap or breadcrumb.
These three levels of templating structure the problem solving. First try to solve it with just a Dreamweaver building block. If this is possible, then your problem is solved, easy as that. If that is not possible, look at the possibilities to respectively use a C# code fragment or a .NET assembly. It should be mentioned that re-use of the Tridion Default Template Building Blocks is preferable to writing it yourself.
Dreamweaver Custom Functions
Next to a template building block, it is possible to add your own functions to a Dreamweaver template by writing so-called custom functions. An example of a custom function is displaying the date or time in a language (and country) specific format, or a custom function to display fields of a different component, e.g. a multimedia metadata field or a field of a linked component. The Dreamweaver Get eXtension (DGX) from Nuno Linhares (available from the SDL Tridion World website) is an excellent example of this. For example to display the alternate text field of a multimedia image in a Dreamweaver templates use the custom function Get():
<img src="@@Get("Fields.Image")@@" alt="@@Get("Fields.Image.Metadata.AltTagField")@@"/>.
Or to display the date in a certain format use the custom function GetDate():
<div>@@GetDate("Fields.Date", "d MMM yyyy", "nl-NL")@@</div>
Level 1: Dreamweaver Template Building Blocks
Example of displaying metadata of a multimedia component
This use-case is to display the metadata field for 'alternate text' of a multimedia image component. When we use the following Dreamweaver template together with the 'Default Finish Actions' TBB the image is rendered without the alt attribute:
<h1>@@Component.Fields.title@@</h1>
< img src="@@Component.Fields.image@@" />
Output:
<h1>Squirrel</h1>
< img src="squirrel.png">
Since the scope of this Dreamweaver template is limited to displaying the current component fields, an extra step is necessary by using the RenderComponentPresentation function. We need to pass the TCM URI of the multimedia component to this function, together with the TCM URI of another Dreamweaver template. So our first Dreamweaver template will look like this:
<h1>@@Component.Fields.title@@</h1>
@@RenderComponentPresentation(Component.Fields.image, RenderMultiMediaTemplate)@@
Instead of hard-coding the TCM ID of the Compound Component Template as the second parameter for the RenderComponentPresentation, it is defined as a parameter named RenderMultiMediaTemplate (using a Parameter Schema). The Dreamweaver template has no dependencies to TCM URIs anymore. The Component Template which already contains TCM URIs has now an extra one. Separation of concerns in full action!
The second Dreamweaver template (RenderMultiMediaTemplate) looks like this:
< img src="@@Component.ID@@" alt="@@Component.MetaData.altText@@" />
This Dreamweaver template now has access to the metadata fields of the multimedia component because we passed the TCM identifier of the multimedia component to it as a parameter.
Note that we now have four templates, two Compound Component Templates and two Dreamweaver Templates.
By using clear and descriptive names for the schemas and templates, it is easy to find them in the SDL Tridion CM and to understand how they work. Because of the simplicity of the templates, it is easy to maintain and extend them; e.g. by adding a title attribute or the width and height attribute. The RenderMultiMediaTemplate depends only on a multimedia schema and can be reused with other content schemas. Since we use the standard SDL Tridion functionality and API the chances are very great that it is compatible with future releases of SDL Tridion web content management systems.
The use of cascading Dreamweaver templates can be applied to other use-cases where a linked component needs to be rendered, e.g. in a Component which has a link to another Component called Content owner.
Second example of displaying different component presentations at different positions
The next example illustrates the use-case of displaying different components at different places in the HTML. For this the standard template language with conditional expressions are used.
<!-- TemplateBeginRepeat name="Components" -->
<!-- TemplateBeginIf cond="ComponentTemplate.Metadata.type=='Portlet'" -->
<!-- TemplateBeginIf cond="TemplateRepeatIndex==1" -->
<div id="content" class="clearfix">
<div class="c-row clearfix">
@@RenderComponentPresentation(Component.ID, ComponentTemplate.ID)@@
<!-- TemplateEndIf -->
<!-- TemplateBeginIf cond="TemplateRepeatIndex==2" -->
@@RenderComponentPresentation(Component.ID, ComponentTemplate.ID)@@
</div>
<!-- TemplateEndIf -->
<!-- TemplateBeginIf cond="TemplateRepeatIndex==3" -->
<div class="c-row clearfix">
@@RenderComponentPresentation(Component.ID, ComponentTemplate.ID)@@
<!-- TemplateEndIf -->
<!-- TemplateBeginIf cond="TemplateRepeatIndex==4" -->
@@RenderComponentPresentation(Component.ID, ComponentTemplate.ID)@@
</div>
</div><!-- content end -->
<!-- TemplateEndIf -->
<!-- TemplateEndIf -->
< !-- TemplateEndRepeat -->
This example shows a simple way of controlling the positions of component-presentations on a page. Since the Component Template Title might be localized in a multi-language blueprint the Metadata of a Template is used to test for a specific Template type.
Conclusion
The examples shown are very simple and very basic and have used by the author in real SDL Tridion implementation projects. These examples show that with some thinking simple Dreamweaver TBBs can be created which fulfill both the functional requirements as well as some of the non-functional requirements. As a programmer we sometimes go too quickly to Visual Studio and start writing a relative heavy solution to fix a simple problem.
For any discussions on this article please see our forum.