Content management systems like Django typically do not embed HTML strings directly in code. They separate the presentation of the data out from the code which assembles the data by using templates. Here is an example Django template taken from a small App Engine project of mine:
<div class="resultsSectionItems"> {% for comment in friend.comments|slice:":29" %} <div><a href="http://friendfeed.com/e/{{ comment.entryObj.entryId }}" ... etc <span class="commentText">{{ comment.commentText }}</span> </div>
Each "{%" block is a template command. This template iterates through comments, creating links.
Templates maintain a separation of responsibilities. The code prepares data structures populated with the data to display. The template iterates over those structures, generating and formatting output. Templates are widespread within content management systems, but they can also be useful in embedded systems work. Some examples:
- Presenting common system data to CLI, embedded web server, and SNMP backends.
- Allowing an OEM to customize the output to include their logos and branding, without having to change code.
- Easier support for multiple languages, as most text should be in templates not code. Templates also tend to compress well, lowering the footprint of internationalization.
Most CMSes are written in Python/Ruby/Java/Perl or other high level languages. There is an opensource C++ templating package by Craig Silverstein at Google called ctemplate. Here is an example which produces a portion of the Apache httpd.conf file based on internal configuration data:
# This file is autogenerated from configuration. Changes will be lost # after the next config change. {{#DIR}}<Directory {{PATH}}> {{#OPTIONS}} Options {{#OPT}}{{VAL}} {{/OPT}}{{/OPTIONS}} Order {{ORDER}} </Directory> {{/DIR}}
Code dealing with populating variables in dictionaries is bolded in the example below, as this is the key point of using ctemplate.
#include <assert.h> #include <ctemplate/template.h> #include <iostream> #include <list> void apache_example() { // Apache <Directory> blocks to create struct ApacheDir { const char* path; std::list<const char*> options; bool deny; } apache_dirs[] = { {"/var/www", {"FollowSymLinks"}, false}, {"/SecretFeature", {"ExecCGI", "-Indexes"}, true}, {"/Tetris", {}, false} }; ctemplate::TemplateDictionary dict("APACHE_EXAMPLE"); int num_dirs = sizeof(apache_dirs) / sizeof(apache_dirs[0]); for (int i = 0; i < num_dirs; ++i) { struct ApacheDir* entry = &apache_dirs[i]; ctemplate::TemplateDictionary* sub_dict = dict.AddSectionDictionary("DIR"); assert(entry->path != NULL); sub_dict->SetValue("PATH", entry->path); std::list<const char*>::const_iterator li; for (li = entry->options.begin(); li != entry->options.end(); ++li) { sub_dict->SetValueAndShowSection("OPT", *li, "OPTIONS"); } sub_dict->SetValue("ORDER", (entry->deny ? "deny,allow" : "allow,deny")); } std::string output; ctemplate::ExpandTemplate("apache.tpl", ctemplate::DO_NOT_STRIP, &dict, &output); std::cout << output << std::endl; }
The example shows some interesting features beyond simple variable substitution. The OPTIONS section is only displayed if there are options present, by using SetValueAndShowSection() in the code. The output of running this code is:
# This file is autogenerated from configuration. Changes will be lost # after the next config change. <Directory /var/www> Options FollowSymLinks Order allow,deny </Directory> <Directory /SecretFeature> Options ExecCGI -Indexes Order deny,allow </Directory> <Directory /Tetris> Order allow,deny </Directory>
Like many other templating systems, ctemplate can apply modifiers to expanded variables. The builtin modifiers mostly concern escaping of HTML, XML, or JSON to avoid common security issues like cross site scripting. It is possible to supply additional variable modifiers by subclassing ctemplate::TemplateModifier. The App Engine example at the top of this article pipes variables through a slice statement to truncate strings to a specific length. We can create equivalent functionality for ctemplate by subclassing the TemplateModifier. The Modify() method is shown in bold, as this is the key part of the implementation.
class MaxlenModifier : public ctemplate::TemplateModifier { virtual void Modify(const char* in, size_t inlen, const ctemplate::PerExpandData* per_expand_data, ctemplate::ExpandEmitter* outbuf, const std::string& arg) const { unsigned int maxlen; if ((sscanf(arg.c_str(), "=%u", &maxlen) == 1) && (maxlen <= inlen)) { outbuf->Emit(std::string(in, maxlen)); } else { outbuf->Emit(in); } } }; void modifier_example() { MaxlenModifier* maxlen = new MaxlenModifier(); if (!(ctemplate::AddModifier("x-maxlen=", maxlen))) { printf("AddModifier failed\n"); exit(1); } ctemplate::TemplateDictionary dict("MAXLEN_TEST"); dict.SetValue("LONGSTRING", "0123456789abcdefghijklmnopqrstuvwxyz0123456789"); std::string output; ctemplate::ExpandTemplate("maxlen.tpl", ctemplate::DO_NOT_STRIP, &dict, &output); std::cout << output << std::endl; }
Our custom modifier is instantiated in the template using x-maxlen=N. Prefixing customer modifiers with "x-" is very strongly encouraged in the ctemplate documentation.
The original string: {{LONGSTRING}} A maxlen=10 string: {{LONGSTRING:x-maxlen=10}} A maxlen=20 string: {{LONGSTRING:x-maxlen=20}} A maxlen=80 string: {{LONGSTRING:x-maxlen=80}}
Here is the output, with the long string truncated to various lengths:
The original string: 0123456789abcdefghijklmnopqrstuvwxyz A maxlen=10 string: 0123456789 A maxlen=20 string: 0123456789abcdefghij A maxlen=80 string: 0123456789abcdefghijklmnopqrstuvwxyz
I've found ctemplate to be quite useful, and I hope others do as well.