This is it. There’s only one thing standing between you and your first fully-functioning Symphony website. Your content’s been sculpted. Your front end is in place and is fielding requests. Data is flowing. All that remains is to give your blog a face, to turn it into something that people can actually use.
In this chapter, you’ll learn how to template a Symphony website—in other words, how to define the output that will be returned to your visitors. Most often, you’ll be outputting HTML pages, but not always. You can also output Atom feeds, JSON documents, raw XML, or pretty much any other text-based format you can imagine. For the sake of your modest blog project, though, we’ll stick to plain old XHTML (XML-flavored HTML), at least for now.
This chapter’s going to be a little more challenging than the previous few. Although Symphony’s templating layer is structurally very simple, conceptually it’s different than systems you may have encountered elsewhere. On top of that, it’s powered by XSLT, which is a language unto itself (and one you may know nothing about). But just because it’s going to be challenging doesn’t mean it can’t be fun. In fact, if I do my job well, you’ll leave this chapter excited about XSLT and eager to learn more.
We’ll start by talking about that conceptual difference, then, in order to explain the unique approach that Symphony takes to templating. After that, I’ll outline the components involved in Symphony’s templating layer (which should be easy—there are only two), and then we’ll dive right into XSLT itself. That’s a book-length topic in its own right, but I’d like to teach you enough that you feel comfortable following along with the remainder of this book. A lot of Symphony’s punch comes straight from this wonderful templating language. Once we’ve gotten through all that, we’ll finish up by writing the templates that will give your new blog a face, even if it’s a fairly plain one.
Note
Until now, I’ve tried to avoid making too many assumptions about how much web development experience you have. This is the exception. I need to be able to trust that you know at least the basics of HTML. If you don’t, I worry that this chapter might be a bit overwhelming for you.
If you’re not confident in your HTML knowledge or think you could use a refresher (or if you’ve never even heard of HTML and at first glance figured it was a leftist political party in Honduras), then it’s probably a good idea to set this book aside for a day and read through a quick introduction to HTML. The folks at http://htmldog.com have an excellent HTML Beginner tutorial.
Before we get started exploring Symphony’s templating layer, though, let’s try a sample exercise to get your feet wet.
You’ll see two tabs in the view editor, "Configuration" and "Template" (Figure 8-1)
Figure 8-1 [f0801.png]
Click "Template"
The view template editor is fairly simple (Figure 8-2). It contains a large textarea for your template code, and a list of available XSLT utilities (more on those later).
Figure 8-2 [f0802.png]
By default, Symphony generates a simple starter template for each new view—just a placeholder that outputs an XHTML page with some basic info about the view and its data. Don’t panic if any of the code scares you. By the end of this chapter, you’ll be comfortable with all of it.
The starter template looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output method="xml"
doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"
doctype-system="http://www.w3.org/TR/xhtml1/DTD/ xhtml1-strict.dtd"
omit-xml-declaration="yes"
encoding="UTF-8"
indent="yes" />
<xsl:template match="/">
<html>
<head>
<title><xsl:value-of select="context/website/name"/></title>
</head>
<body>
<h1><xsl:value-of select="context/view/title"/></h1>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
On the whole the syntax should feel vaguely familiar, and if you’ve got a keen eye you’ll notice some HTML in there. For now, we’re just going to make some very simple changes to this template so it will output the entry titles being returned by your Recent Posts data source.
Just below the line containing <h1><xsl:value-of select="data/context/view/title"/></h1>, enter:
<h2>Recent Posts</h2>
<ul>
<xsl:apply-templates select="recent-posts/entry"/>
</ul>
Translation
"Output a second-level header (
h2) element containing the text Recent Posts, followed by an unordered list (ul) element. Inside the unordered list, I want you to apply templates to the entry items being returned by my Recent Posts data source."
Now, after </xsl:template> and before </xsl:stylesheet>, enter:
<xsl:template match="recent-posts/entry">
<li>
<xsl:value-of select="title"/>
</li>
</xsl:template>
Translation
"Here’s the template I want you to use for those entry items. Just create a list item (
li) element and inside it output the entry’s title."Your final template should look like this (I’ve emphasized the bits I asked you to add):
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output method="xml"
doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"
doctype-system="http://www.w3.org/TR/xhtml1/DTD/ xhtml1-strict.dtd"
omit-xml-declaration="yes"
encoding="UTF-8"
indent="yes" />
<xsl:template match="/">
<html>
<head>
<title><xsl:value-of select="context/website/name"/></title>
</head>
<body>
<h1><xsl:value-of select="context/view/title"/></h1>
<h2>Recent Posts</h2>
<ul>
<xsl:apply-templates select="recent-posts/entry"/>
</ul>
</body>
</html>
</xsl:template>
<xsl:template match="recent-posts/entry">
<li>
<xsl:value-of select="title"/>
</li>
</xsl:template>
</xsl:stylesheet>
Click "Save Changes"
If you visit your Home view now, you should see something like Figure 8-3.
Figure 8-3 [f0803.png]
It’s pretty barebones at the moment, I’ll admit, but it’s something. The content that you modeled and created yourself back in Chapter 5 has finally found its way to your adoring public.
Now, if you’ve never seen XML or XSLT before, that exercise might have been a little intimidating. Don’t worry. Like me, it’s actually far simpler than it looks. Before we get into figuring out how to crack all that code, though, let’s review exactly how templating works in Symphony.
Loosely speaking, templating is how a web application prepares the output that it will render to its users. There are lots of different kinds of web templating systems out there, each with its own virtues (and shortcomings), but the majority of them can probably be said to take one of two approaches:
Of course, this is an oversimplification, and there are certainly exceptions, but in my experience these do seem to be the dominant paradigms. If you've done any web development before, chances are you're familiar with one or both of them.
The parsed output approach has the benefit of being fairly simple and easier for beginners to grasp. If you already know how to write HTML, for example, you can can just whip up your templates as normal and then drop in a few copied-and-pasted tags where necessary.
The programmed output approach, on the other hand, is very powerful, because you can lean on the full capabilities of a robust programming language like PHP, Python, or Ruby. If you know the language well, you can do pretty much anything you want in the course of generating your output.
Both can and have been used to great effect, but they usually have significant drawbacks too. Parsed output, for example, tends to be very limited, both in terms of the data you can access and what you’re able to do with it. These systems often rely on a narrowly-defined custom syntax or set of functions that’s fairly shallow and not useful in other contexts.
Programmed output, on the other hand, has a pretty high barrier of entry for designers and other non-programmers. More importantly, though, it subjects you to the procedural constraints of languages that aren’t really designed for templating. These kinds of systems can easily get messy because often there is no clear distinction between the presentation logic and, well, everything else.
Whichever approach they take, the vast majority of web templating systems make it difficult or impossible to intelligently organize and reuse code, and they nearly always leave their dirty little fingerprints all over your output. As a result, in many systems, templating on the whole can often feel like an afterthought—something pieced together and tacked onto a system just to allow its content to be turned into HTML and decorated.
Symphony’s approach doesn’t really fall on this spectrum. It’s a radically different tack, one you might call "transformed output." With it, you craft a standalone system of stylesheets with rules for turning the raw data delivered by the system into some sort of digestible format. So rather than having you write output laced with procedural code, or procedural code laced with output, Symphony's templating system is an entirely self-contained layer, powered by a language that was designed just for templating (XSLT).
This can be a little disorienting if you're accustomed to other kinds of systems, and it isn't without its own drawbacks. For starters, XSLT can involve a bigger learning curve than simple tag-based template syntaxes, and it's more verbose (although some people like that about it). There are also things that XSLT can't do as easily as a full-fledged programming language can.
That said, though, the benefits of a transformed output approach far outweigh these minor gripes. First of all, you have complete, unfettered access to all the raw data you need to craft your presentation. Also, as I said above, the templating layer is completely self-contained, which means it’s clean and lean, and the system can’t interfere with your output in any way. This self-containment also means that your code can be organized elegantly and reused. Finally, and perhaps most importantly, you get all the benefits of a dedicated, open templating language in XSLT. We’ll talk about what those benefits are in a moment.
So what does Symphony’s implementation of this approach look like?
As you’ve seen, when someone visits your Symphony site's front end, a view handles their request and goes on to build the XML data that will power the view and its interactions. But this isn't what gets delivered to your visitor. Instead, it’s left entirely up to the templating layer to transform that raw data into some sort of usable output.
The templating layer is made up of view templates and XSLT utilities. Every view has an accompanying view template that it uses to transform its source XML. XSLT utilities are more generic and can be included in these transformations at will. Figure 8-4 illustrates the templating process:
Figure 8-4 [f0804.png]
Both view templates and XSLT utilities are simply vanilla XSLT stylesheets. No custom syntax or special processing required. So in order to understand how Symphony’s templating system works, you just need to understand how XSLT works.
To help you get there, I'm going to whisk you through a basic introduction to XSLT at neck-breaking speed. I hope you’re wearing a helmet. (Not because you need protection, though. It’s just funny to imagine you reading this book with a helmet on.)
Ok, ready?
XSLT is the keystone in a trio of languages developed to transform and format XML. Collectively, those languages are known as XSL, or Extensible Stylesheet Language.
Each member of the XSL family has a specific role:
In the Symphony context, we only need to talk about the first two. XSL-FO can be useful for things like PDF-generation, but that sort of thing is a bit advanced for this book.
Though the usage of XSLT as a web templating language is not exactly commonplace, there are lots of factors that make it ideal for this exact purpose. Here’s a handful of them:
In short, XSLT is what one might call "awesomecake," and after reading about all the ways it can make your life easier, there’s a good chance you’re standing up doing fist pumps right now. With your helmet on. Which is fantastic.
So here’s how it all works...
XSLT defines sets of instructions that are used to transform source XML and create some kind of output (Figure 8-5).
Figure 8-5 [f0805.png]
Let’s look at a few very simplistic examples of this process to give you an idea of what I mean. Just try to follow along as best you can, but don’t panic if anything confuses you—we’ll go through it all in more detail below.
Imagine that you have the following XML content:
<book>
<title>Symphony Start to Finish</title>
<author>Craig Zheng</author>
</book>
We’ll assume you don’t need to do anything fancy with it—you just want to output the book’s title. In your XSLT stylesheet, the first thing you’d do is write a template rule that matches that book element:
<xsl:template match="book">
… do stuff …
</xsl:template>
Now anything you put inside this template will be used to generate output when that element gets processed. Since you just want to spit out the book’s title, you’d write:
<xsl:template match="book">
<xsl:value-of select="title"/>
</xsl:template>
That template, applied to the XML above, would just output the text from the title element:
Symphony Start to Finish
And if you wanted to output XML or HTML, you would do something like this:
<xsl:template match="book">
<h1><xsl:value-of select="title"/></h1>
</xsl:template>
That transformation would get you this output:
<h1>Symphony Start to Finish</h1>
Not too bad so far, right? Before we get into the nitty gritty details of the language, let’s step back and review what’s actually going on during an XSLT transformation.
Imagine you’re my personal assistant (I’m liking this example already). I have several stacks of unorganized books, and I want you to help me create a catalog. So I ask you to sift through the books, one by one, and do the following:
What I’ve done is I’ve asked you to process a bunch of content, and I’ve given you some instructions telling you what to do for each item you come across. When you’re finished, I’ll have a nifty spreadsheet and a stack of cover images.
This is more or less how XSLT works. A processor starts with some XML content, and as it parses that content, it uses instructions from an XSLT stylesheet to generate some other sort of output.
When you write XSLT stylesheets, then, you’re essentially creating systems of rules and instructions.
Note
If you’re familiar with other programming languages, this might take some getting used to. Many common programming languages are imperative—they issue lots of commands, one after the other. And as you saw above, lots of web developers are accustomed to systems that rely on imperative languages for templating—they might even begin to think about building output as a series of commands: First include the head, then loop through entries, then include this other snippet...
XSLT, on the other hand, is a declarative language. Instead of issuing commands, it simply states what should be done in a given context. It’s rather similar to CSS in that way. Neither language describes a sequence of events or functions. They just say, "Hey, when you come across this element, this is how you should style/transform it."
Templating with this kind of rule-based language takes a different sort of mindset, but it’s actually a much more powerful and flexible approach. A list of commands can only be followed, but rules can have scope and interdependencies, they can cascade, they can override one another.
You might not fully understand what I mean here, and as I said above, this is really a book-length topic of its own. My hope is just that by the end of this book you’ll have seen enough of XSLT’s power as a web templating language that you’ll want to go and spend a little bit of time learning it in earnest.
Now that you’ve gotten an overview, let’s walk through what’s happening during one of these transformations. I’ll begin by explaining how an XSLT processor sees and interprets its source XML. Then we’ll talk about how a stylesheet’s instructions are applied and what they can do. We’ll finish up with a brief review of stylesheet structure and organization.
The first thing the processor does during a transformation is load the source XML. It needs to parse all of the data into a document tree—a hierarchy of identifiable bits called nodes—so that the stylesheet can work with it. Let’s look at how XML data is broken down.
Note
We’ll stick to the basics here—if you want a detailed history of the language or a thorough breakdown, there are much better places to get it than this. We’re just going to concern ourselves with what you need to know in order to grasp the fundamentals of XSLT.
XML is a markup language, which basically means that you use it to describe content in some way. For example, look at this text:
Amazon
That could be any of a half-dozen things—the internet company, the rainforest, the mythical tribe of female warriors. So let’s use XML to mark it up:
<river>Amazon</river>
Ok, now the text has got some meaning attached to it. You’re no longer just looking at some ambiguous word but at a meaningful XML element.
At its very simplest, XML is made up of elements like this—just various things that exist in the universe of a particular XML document. A menu, for example, might have elements like dish and beverage, while a real estate listing might have elements like house or apartment.
Elements are identified by tags. In the example above,
<river>
<name>Amazon</name>
</river>
If an element hasn’t got any content at all, the opening tag can simply close itself:
<river />
Elements can also have attributes—key-value pairs that store additional information for the element:
<river continent="South America" miles="4200">Amazon</river>
Taken all together, the basic ingredients of XML syntax are pretty straightforward:
<element-name attribute="value">text content</element-name>
Each of them—elements, attributes, and text—is a different kind of node that can be identified and processed during an XSLT transformation.
Now, if you’ve ever written any HTML in your life, all of this should look pretty familiar. If not, I’m fairly certain you won’t have any trouble catching on. After all, the syntax, by definition, is descriptive. Let’s imagine what a house might look like, for example, if we described it with XML:
<house color="yellow" square-feet="2560" style="colonial">
<room square-feet="420" type="kitchen"/>
<room square-feet="660" type="bedroom"/>
...
</house>
Not too difficult, right? We’ve got a house element with a few descriptive attributes and a couple of room elements for children.
Now let’s look at a snippet of the XML that your Recent Posts data source is providing to your Home view:
<recent-posts>
<entry id="2">
<title handle="my-second-post">My Second Post</title>
<category handle="journal">Journal</category>
<publish-date>2011-01-21</publish-date>
</entry>
<entry id="1">
<title handle="my-first-post">My First Post</title>
<category handle="journal">Journal</category>
<publish-date>2011-01-19</publish-date>
</entry>
</recent-posts>
If you can parse the above and identify the two entries and the various nodes that comprise them, then congratulations... you’re already conversant in XML! (You must have a really fantastic teacher.) And you’ll be glad to know that XSLT is itself an XML format, which means you already have a basic understanding of its syntax!
Note
This is all simplified, of course. There are lots of little rules and wrinkles that you’ll have to learn. For instance, XML is a very strict language and most use cases require it to be well-formed—meaning elements must be nested properly, closed properly, contain only valid characters, and so on. But we’ll cover most of those rules as we go along. No need to get bogged down right now.
So, as I was saying above, once the XSLT processor loads an XML source document, it begins stepping through its nodes, one by one. Let’s look at the XML for your Home view to see how this works. You can see the source for yourself at http://example.com/?debug, but I’ll paste a sample here for reference:
<data>
<context>
<view>
<title>Home</title>
<handle>home</handle>
<path>/</path>
<current-url>http://example.com/</current-url>
</view>
<system>
<site-name>Tales of a Highway Bandit Hacker</site-name>
<site-url>http://example.com</site-url>
<admin-url> http://example.com/symphony</admin-url>
<symphony-version>3.0</symphony-version>
</system>
<date>
<today>2011-01-25</today>
<current-time>19:03</current-time>
<this-year>2011</this-year>
<this-month>01</this-month>
<this-day>25</this-day>
<timezone>America/New_York</timezone>
</date>
...
</context>
<recent-posts section="blog-posts">
<entry id="2">
<title mode="formatted" handle="my-second-entry">My Second entry</title>
<body mode="formatted">is flavored like potato.</body>
<publish-date time="15:38" weekday="6">2011-02-12</publish-date>
<category handle="journal">Journal</category>
</entry>
<entry id="1">
<title mode="formatted" handle="my-first-entry">My First Entry</title>
<body mode="formatted">Is flavored like awesomesauce</body>
<publish-date time="15:38" weekday="3">2011-01-12</publish-date>
<category handle="journal">Journal</category>
</entry>
</recent-posts>
</data>
The processor starts at the root (or document) node, which is a node that contains the entire source tree. It then processes the top-most element (in this case, data), and begins working through its children one by one. First up would be the context element—the processor would crawl down through each of its descendants (view, title, handle, path… system, site-name, and so on). Then it would proceed to the data element and crawl through its descendants, and their attributes and contents.
As it’s stepping through XML like this, the processor checks the stylesheet for any instructions that it should apply to a particular node in order to generate output.
Let’s talk about how those instructions work.
Templates are where all of the action happens, as you saw in some of the simple examples above. They are the real meat of an XSLT stylesheet, and they define most of what happens during a transformation—building output, specifying logic, routing the processor, and so on.
There are two types of templates, template rules (sometimes called "matching templates") and named templates. Both are defined using xsl:template elements. The stylesheet you’re using to transform the XML above has two templates in it:
<xsl:template match="/">
<html>
<head>
<title><xsl:value-of select="data/context/website/name"/></title>
</head>
<body>
<h1><xsl:value-of select="data/context/view/title"/></h1>
<h2>Recent Posts</h2>
<ul>
<xsl:apply-templates select="data/recent-posts/entry"/>
</ul>
</body>
</html>
</xsl:template>
<xsl:template match="recent-posts/entry">
<li>
<xsl:value-of select="title"/>
</li>
</xsl:template>
Both of these are template rules—they specify the nodes to which they should be applied using a pattern in their match attribute (more on those patterns in a moment). When the processor reaches nodes that match the pattern, it follows the instructions provided by the template. Template rules can have more than one match pattern (they’re separated by the pipe character, |), meaning the same template can be used to process different node-sets.
The other kind of template, the named template, isn’t matched to the source tree but rather is invoked explicitly. We’ll discuss these more in depth a bit later.
Note
If you’re accustomed to writing CSS rules, which have a selector and then a set of declarations, template rules are sort of an analogous structure. The match attribute contains the "selector," and then the template contains details about how the selected node is to be handled:
<xsl:template match="recent-posts/entry"> … do stuff … </xsl:template>
Template rules are matched to source nodes using XPath patterns. Let’s look at the two that are used in the stylesheet above:
/
and
recent-posts/entry
Each of these patterns is used to match the template to a particular node or node-set in the source XML. The first matches the root node; the second matches entry elements that are children of a recent-posts element.
A great deal of what templates do depends on being able to select or match nodes in the source tree like this, so let’s take a quick detour into the world of XPath so you can get a sense of how these expressions work.
Note
The debug devkit actually allows you to test XPath expressions live on your source XML. If you go to
http://example.com/?debug, you’ll see an XPath expression bar (it’s got//*in it by default). Any XPath expression you type into that bar will highlight the matching node or nodes in the source XML. It’s a tremendously helpful tool for learning XPath. As we walk through the various kinds of XPath expressions in this section, feel free to test them out. You can also experiment with expressions of your own to get a sense of what works and what doesn’t.
XPath is designed specifically to enable you to identify nodes or node-sets in an XML tree. There are several types of nodes, as you’ve seen: the root node, element nodes, attribute nodes, and text nodes (along with a few others that aren’t really important for us at the moment).
XSLT transformations rely on XPath extensively, because you have to identify nodes in the source tree in all kinds of contexts—when you’re defining template rules, when you’re grabbing and manipulating source content, when you’re giving instructions to the processor, and so on.
Thankfully, XPath provides a very powerful and versatile syntax for building all kinds of expressions. Expressions allow you to pinpoint nodes based on their location, their node type, and even their contents and values.
Note
Patterns, like the ones you saw above, are a subset of XPath expressions that are used in specific contexts (like template match attributes). While expressions as a whole are written to target particular nodes in a source tree, patterns allow you to specify conditions that you want nodes to meet in order to be considered a match. The difference is subtle, but it can be important. You’ll see why in a moment.
The simplest kind of expression is a path expression, which is used to select nodes based on where they are in the tree. These will look familiar to you because they work very much like filesystem paths and URLs.
If you look back at your home view’s XML, for example, you could select the current date with the following expression:
/context/date/today
Easy enough, right? Each bit is the name of an element, and each slash indicates a level in the hierarchy.
Note
Path Expressions and Context
When you’re describing locations like this, context becomes an important factor.
Patterns are not evaluated relative to any context because they’re just general conditions that nodes need to match. So something like
match="entry"will apply to any entry element in the entire source tree, andmatch="recent-posts/entry"will apply to all entry elements that are a child of a recent-posts element.Expressions in general, though, are evaluated relative to the node being processed. So if you have a template rule that matches
/context/date, any XPath you use inside that template has to be relative to the date element. Path expressions likeentryandrecent-posts/entrywouldn’t work because those elements don’t exist inside the date element.When you’re dealing with relative paths like this, you have to be able to move around the source tree. XPath makes this possible with axes (this is an advanced topic, so I’ll just give you the highlights and you can read up on your own). There are 13 axes, among them
parent::,ancestor::,descendent::,following::, and so on. Each allows you to navigate through the source tree in a different way.The default axis in XPath is
child::(meaning entry is the same aschild::entry). The other axes enable you to select nodes that are not children or direct descendents of the current context node.Many axes have shorthand equivalents, so
../contextis the same asparent::context(just like in a file system), and//entryis the same asdescendent-or-self::entry(it’ll look for entry elements at any depth from the context node).Aside from using axes, the other way to sidestep the current node’s context is to make an expression root-relative by preceding it with a forward slash:
/context. You can then build your expression to target a node based on its location from the root.
These path expressions should be pretty intuitive, and I’m sure you’ll pick them up quickly, so I’ll leave it at that for now.
The expressions we’ve seen so far only match element nodes. You can select attribute nodes and text nodes just as easily, though. To target an attribute node, you just prepend @ before its name: @id. In a path expression, an element’s attributes go at the same level in the hierarchy as its children:
//entry/@id
There are also times when you don’t want to select an entire element, only its text content. In that case, you’d use text() to specifically target the text node:
/context/view/title/text()
You can also select nodes based on various conditions. Let’s say, for instance, that you only want to select the Recent Posts entry element whose id attribute is 2:
/data/recent-posts/entry[@id = ‘2’]
Or you only want to select the last entry in the source:
//entry[last()]
The part of the expression that appears in brackets is called a predicate. Predicates allow you to specify additional conditions for selecting a node. The predicate doesn’t always have to come at the end of the expression, either:
/data/recent-posts/entry[@id = 2]/title/@handle
Cool, huh?
There’s a lot more to XPath than this—the * wildcard, for instance, and functions like position(), count(), and substring(), but we’ll continue to flesh that stuff out over the rest of the book. This should be enough for now.
If you’ve done much web development, hopefully XPath syntax feels sort of natural to you. It’s actually not unlike many other selector languages, and the very popular jQuery framework actually supports some XPath syntax itself. If you’re confused, though, you might want to read up a bit on your own before we get into more advanced XSLT techniques in later chapters.
Anyway, now that you’ve gotten a rundown of XPath syntax, let’s get back to the task at hand—explaining the role that templates play in an XSLT transformation.
A processor takes nearly all of its instructions from templates, so they’ve got to be able to do everything from establishing the structure of an output document and defining processing logic to grabbing, manipulating, and outputting data.
One of the most important things a template can do is organize output and control processor flow during a transformation. You see this at work in your Home view template.
You’ll recall that, above, I said that an XSLT processor steps through a source tree node by node. That’s its default behavior. XSLT also specifies a default template (used when it can’t find a matching template for the node it’s processing). The default template essentially just spits out any text content it finds.
If those are both default behaviors, why isn’t all the text in your Home view’s source XML just dumped out onto the page?
The key is that, when the processor does find a template to apply, it defers to the template to tell it what to do. So that first template rule in your stylesheet, the one that matches the root node (match="/"), effectively seizes control of the entire transformation from the outset. If you were to write an empty template rule matching the root node:
<xsl:template match="/">
</xsl:template>
the processor would simply stop there and output nothing at all. It wouldn’t step through any of remaining nodes unless you told it to.
In your Home view template, then, the first template rule matches the root node and stops the processor from going about its normal business. Then it builds the overall structure for an XHTML page, and explicitly tells the processor where and how to proceed using the xsl:apply-templates element:
<xsl:template match="/">
<html>
<head>
<title><xsl:value-of select="data/context/website/name"/></title>
</head>
<body>
<h1><xsl:value-of select="data/context/view/title"/></h1>
<h2>Recent Posts</h2>
<ul>
<xsl:apply-templates select="data/recent-posts/entry"/>
</ul>
</body>
</html>
</xsl:template>
If used without a select attribute (i.e. just <xsl:apply-templates/>), this element would just send the processor back on its merry way, to resume its normal processing flow. In the example above, though, you actually don’t want it crawling through all of the XML; you have a specific template you want it to apply in a very specific place, so you direct it to the nodes that match that template.