Example Use Cases
A web content management system generates web pages. The HTML is generated from a set of templates, separate from the source code.
An email marketing system uses templates to form the body of an email. The template is edited through a UI and allows the editor to enter placeholders that are replaced with specific data.
Relation to the Application
Templating is often a separate subsystem, defined along several characteristics:
Language: Templates are usually in a language other than the core language of the application. This language has specific features designed for outputting custom text.
Computational Space: Template code is often executed in a “sandboxed” computational space, separated from the main application. Errors in templates are (or should be) contained and managed without a negative on the stability of the application.
Code Management: Template code is often managed separately from other integration code. It’s sometimes in files in a different storage mechanism, and is sometimes managed directly from the application UI through a browser-based IDE.
Intended Developer: A “template developer” is sometimes a separate role than an “integration” or “backend” developer. This developer is usually skilled in front-end technologies (HTML, CSS< JavaScript) and also learns the templating tools of the application.
Sometimes, of course, none of these are true. An application might do templating in the same language as the application, executed in the same process, with files in the same location, coded by the same developer. The differences are a matter of degree.
A key point: the output of a templating operating is usually intended as a final stage of delivery, to be sent to a consuming device or platform. Very rarely is the output of templating re-incorporated into application logic or operated on in any other way. Data is templated at the last moment before delivery, then it leaves the application context.
The Two Philosophies of Templating
There are two competing theories of how templates should interact with the application:
Weak Templates: Templates should be limited in both data and features. They should only be able to interact with data “given” to them, and they should have a very limited logical featureset. Having logic inside templates just creates another level of code and potential issues, often written by a developer not familiar with the larger application.
Strong Templates: Templates should have most of the logical features of the “full” programming language, and should even be able to retrieve data beyond that which is provided to them. A templating language only exists to provide a layer of computational sandboxing, features specifically designed for the manipulation of text, and the convenience of a separate DevOps context.
Most systems will exist somewhere in the middle. In particular, the weak templating philosophy has some vocal adherents for “logic-less” templates, but it imposes considerable limitations on template development that often frustrate developers working with it.
The Template “Context”
Most all templating languages operate on the idea of a special “sandbox” or context in which the template executes. The templating language will have access to the data specifically injected into this context, or the results of functions made available to that context, and nothing else.