Over the years it has become more and more common practice amongst developers to separate appearance of an application from the logic behind it. There are quite a few reasons for this move. One of those reasons is to allow for automated testing, another is to allow designers and developers to collaborate more easily on a project. And if you google around a bit, you’re bound to find quite a few more reasons, but that’s not what I’m getting at here.

Less dependency between developer and designer

In DotNetNuke development – or any other modular platform for that matter - there’s another reason for it: flexibility for the administrator or designer. If I (as a developer) need to build a module for a customer’s website, chances are that the design is not yet fully ready when I’m developing the module. If I can develop the module without having to decide on specific layout-issues, that’ll mean more freedom to me, less dependency in the project (I’m not waiting for the design, nor is the design waiting for me).

Creating Templateable modules

This flexibility can be achieved by creating templateable modules. Templateable modules offer a designer or administrator an option to completely change the appearance of a module without any need to get the developer to do anything.

So, how do you make your module templateable? Well, without getting into too much detail in this post, the key here is the DotNetNuke Built-In Tokenreplace Services. Tokenreplace consists of a set of classes that allow you – as a developer – to implement templating without the hassle of performing search & replace in a lot of strings. With Tokenreplace implemented for your module, your administrator or designer can build templates containing so-called tokens (text between square brackets, like [USERNAME]) which will then run-time be replaced by real values.