Translate
In this series of articles, a unified way of working with the Compound Templating Framework is presented. Part one started with Dreamweaver Template Building Blocks, this part is a continuation of part one and describes Custom Functions for Dreamweaver TBBs. The other parts cover C# fragment Building Blocks and .NET assembly Building Blocks.
Part 2
This unified way of using Templates is to keep things (i.e. Template Building Blocks) simple. This is done by adding complexity (i.e. code) only when necessary and at the right level. Start with a Compound Template with the basic Dreamweaver template building block without any programming logic. When the requirements demand decision-making or programming-logic then add complexity at the right level. This article discusses the Dreamweaver Custom Functions. Let's first summarize and then continue with the article.
The different levels of templating
Level 1: Dreamweaver templates
The first level of templating is the use of only Dreamweaver TBBs to display the (metadata) fields of a Component or Page by using the placeholders. Or call built-in functions. Examples are:
@@Page.Title@@
@@Component.Fields.myField@@
@@TemplateRepeatIndex@@
@@RenderComponentPresentation()@@
@@RenderComponentField(...)@@
For a complete list see the members of the class BuiltInFunctions in the TOM.NET API help-file.
Use the Dreamweaver expression language for decision making or logic within the template. Examples of this are the Repeat, Conditional or Parameter instructions:
< !-- TemplateBeginRepeat name="Components" --> . . . <!-- TemplateEndRepeat -->
< !-- TemplateBeginIf cond="BooleanExpression" --> . . .<!-- TemplateEndIf -->
< !-- TemplateParam name="Page" type="boolean" value="true" -->
For a complete list see the "Sample Compound Template" generated by the Template Builder.
Level 2: Dreamweaver Custom Functions
The next level is to add your own functions - when requirements demand it - to a Dreamweaver template building block. These Custom Functions are functions between the @@ placeholders.
There are two reasons for considering custom functions first:
-
Functions have arguments, whereas variables have not
E.g. @@GetDate("Fields.Date", "d MMM yyyy", "nl-NL")@@ versus @@dateDMY@@ -
Functions are the most generic, they are stored on the filesystem and not in the database
Some examples which are - in my opinion - best solved using custom functions: the formatting of a date field or to test if the page is previewed. These are so generic and are independent of any website, project or client. You write those custom functions once and won't need to touch them again.
Some examples which are - again in my opinion - no candidates for a custom function are site-specific or presentation-specific to support a one-of-a-kind functionality in a component-template.
Other levels: C# code fragments and .NET assembly
If the requirements does not demand a generic solution then look to implement it as a C# fragment (a few lines of code), or as a .NET assembly. Don't fall into the trap of making everything generic so that it can be re-used later. This will be covered and discussed in the next articles.
For any discussions on this article please see our forum.