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.
Also I'll state again: the speed of light in fiber only matters for wide area links. The propagation delay in 100 meters of fiber is dwarfed by queueing and software delays, to the point of insignificance. In fact if we could reduce the cost or power consumption of short range lasers by making the speed of light even slower in the fiber they drive, that would be a good tradeoff.
In January 
Fiber optic strands have a central core of material with a high refractive index surrounded by a jacket of material with a slightly lower index. The ratio of the two is set to cause total internal reflection, where the light is confined to the central region and won't diffuse out into the cladding.
As it was located near the center of the US auto industry, there was an extensive automotive program at the University of Michigan (Ann Arbor) with an assortment of guest speakers from the Big Three. I went to several presentations that made quite an impression. One of them was about self-driving cars... in 1991.
