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?
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:
- Reading from generated xml files – i.e. Applications.xml
- Retrieving data from external sources – i.e. retrieving data from a product catalog.
- 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:
- Data coming from the xml displayed as foldable headers and tables where every row represents an application version which is still supported.
- A price of a product retrieved from a product catalog
- 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.
