Movable Type Templates


Template and Tag Philosophy

There are two main ideas behind Movable Type's template tags:

Both of these points are described in more detail below. For users of other content management systems, who are more familiar with other template tags, here are some notes on the differences in the mental models.

Why does Movable Type use the mental model that it does for templates? Two reasons:

  1. The primary reason is flexibility. You can use the <MTEntries> tag to represent any list of your entries, and you can style that list however you want, in many different places. Contrast this with Greymatter's approach, where the {{logbody}} is always replaced by a list of entries styled using the exact same markup: the markup in one of the two Index Entry Templates templates.

  2. You have less templates to keep track of, and you have all of the markup for one page laid out in one template. Greymatter's approach is generally to break up a page into small little chunks, each of which is considered a template. In Movable Type's template system, all of the markup is in one place, and is included/not included, or repeated, using container tags.

(Note that the above is not intended as a criticism of Greymatter; it is simply meant to illustrate the differences, and to describe why we chose to do things the way we did.)

Tag Types

Movable Type templates are composed of special tags embedded within standard chunks of plain text (or HTML, as the case may be). The set of tags can be broken into two groups, containers and variables:

Tag Syntax

All Movable Type tags are enclosed within less-than greater-than signs, just like HTML tags. You can optionally insert a $ inside these signs, like this:


This can be useful to quickly determine whether a particular tag is an HTML tag or a Movable Type tag.

The $ is optional; a convention that is followed throughout the default templates and the documentation is to use the $ on Variable Tags, but not on Container Tags. Part of the reason for this is that you should not use the $ on the end tag of a Container Tag, because the system will then be unable to find the end tag.

Tag Attributes

Some Movable Type tags take attributes that modify their default behavior. Tag attributes work similarly to HTML tag attributes: they are lists of name="value" pairs, separated by spaces. For example:

<MTEntries author="Foo" category="Bar">

(Look at the <MTEntries> documentation to determine what this does.)

Attribute values must be enclosed in quotes; otherwise they will not be parsed correctly. When using attributes in a tag where you are using the $ character after the start and before the end tags, you should place the attributes before the end $ character. For example:

<$MTEntryDate format="%B %e, %Y"$>

The attributes supported by the various Movable Type tags are listed along with the tags.

The Importance of Context

Most Movable Type tags are context-dependent, meaning that they should only be used in the appropriate context.

Context is generally determined by either the surrounding template or the surrounding container tags: for example, template markup is placed in entry context either within an <MTEntries> tag, in an Individual Entry archive page, in a Comment Listing template, or in a Comment Preview template. Because of this, it only makes sense to use an <$MTEntryTitle$> tag, or an <MTComments> container, inside one of these contexts.

Technical Information

Following is some technical information on how templates are parsed and built into output pages.

The first step is breaking up the incoming template into tokens, where each token is either a tag (<$MTEntryText$>, <MTEntries>, etc.) or a block of raw text to be inserted directly. Some tags are containers, like <MTEntries>--these tags must contain both an opening tag and a closing tag, and the subtemplate markup between is also tokenized, and is stored beneath the container.

The second step is taking these tokens, along with an entry, a list of entries, a comment, a list of comments, etc.--basically, some sort of context--and building a final output page. Generally this final page will be HTML, although the system has no such restrictions, obviously (considering that it comes with a template for RSS syndication already installed).

The tags themselves are not hard-coded into the parser (the object that compiles the text into tokens); every time the parser finds a tag, it asks the context object what type of tag it is, whether it is a container, etc. The tag is then added to the list of tokens.

Likewise the tags are not hard-coded into the object that builds the final output (the interpreter, essentially). This object also communicates with the context object, and for each tag it handles, an anonymous subroutine--which has been registered with the context object upon its creation--is invoked. This subroutine returns a block of output to be directly inserted into the final output.