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.
<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.
{{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:
<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.
(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.)
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:
<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'').
<$MTEntryTitle$>
tag is replaced with the title of the entry.
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.
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.
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.
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.