### Movable Type Templates

- MOVABLE TYPE TEMPLATES

- Template and Tag Philosophy
- Tag Types
- Tag Syntax
- Tag Attributes
- The Importance of Context
- Technical Information

# MOVABLE TYPE TEMPLATES

## Template and Tag Philosophy

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

- Context is important in determining when you can use a particular tag.

- Container tags represent lists and conditionals, and variable tags represent variable substitutions.

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.

- Blogger
  Movable Type's template tags are very similar in spirit to Blogger's. In Blogger, you use a `<Blogger>` tag to surround the list of your entries; then you use `<$Blog*$>` tags to represent variable substitutions.

  Converting this model to Movable Type is very easy.

  The `<Blogger>` and `</Blogger>` tags are replaced by `<MTEntries>` and `</MTEntries>` tags, respectively.

  The `<$Blog*$>` tags are replaced by similarly-named `<$MTEntry*$>` tags.

  Of course, Movable Type has quite a few more template tags than does Blogger, but the mental models are very similar.

- Greymatter
  Greymatter's template tags use a different mental model than Movable Type; in Greymatter, for example, when you want to insert a list of all of your entries on your index page, you insert the `{{logbody}}` tag. Then you customize two other templates--`Index Entry Template: Standard Entries` and `Index Entry Template: Extended Entries`--to style each of the entries in the list on your index page.

  Converting this model to Movable Type, then, is done like this:

  The `{{logbody}}` tag is replaced by an `<MTEntries>` container.

  The markup in `Index Entry Template: Standard Entries` and `Index Entry Template: Extended Entries` is combined to form the markup between the `<MTEntries>` and `</MTEntries>` tags. Any markup that you want only to appear for extended entries should be enclosed in an `<MTEntryIfExtended>` container. And, of course, you change the Greymatter variable substitution tags to the corresponding Movable Type tags.

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:

- Container Tags
  Certain MT tags are ``container'' tags; they contain what might be called a subtemplate, a chunk of text and MT tags between two other MT tags: the start of the container and the end of the container. For example, if we have a tag called `<MTFoo>`, you might see the following markup in one of your templates:

      <MTFoo>
      Foo bar
      </MTFoo>

  The start and end tags for a container look like standard HTML tags.

  Container tags represent either a list or a conditional.

  If a container represents a list--the `<MTEntries>` tag, for example--the subtemplate within the container will be applied to each of the items in that list. For example, when you use an `<MTEntries>` tag, the markup between <MTEntries> and </MTEntries> is applied to each of the entries in the list.

  If a container represents a conditional--the `<MTEntryIfExtended>` tag, for example--the markup between the start and end tags will only be displayed if a certain condition is met. For example, in the case of `<MTEntryIfExtended>`, the condition tests whether the entry has an extended piece (``more text'').

- Variable Tags
  All non-container tags are simple variable substitution tags. They are placeholders for dynamic pieces of information. For example, the `<$MTEntryTitle$>` tag is replaced with the title of the entry.

## 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:

    <$MTEntryBody$>

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.

Copyright © 2001-2003 Six Apart. All Rights Reserved.