When I started the last iteration of Christian Lyrics I spent a lot of time looking for the best way to cache my data and templates. I wanted each page load to do as little as possible. Unfortunately most of the templating engines I saw had medicore cache control at best, and it was starting to look like I need to work on a new one. Then I found XSL. I had already fallen in love with SimpleXML and DOM, and with XSL I was able to utlize both for views. I’m not going into detail how my view class works, instead I’m just going to cover the caching techniques I use. So let’s get started!

Most new sites have some form of login, and usually there is a block on each page with your user info. Take, for example, Christian Lyrics. It has a “My Account” box in the left menu that shows a log in form for Guests and some information about your account if you log in. I wanted everything on the home page, except for the user box, to be cached for a specified amount of time. With normal templating systems this required caching the “compiled” templates with whatever data inside of it and where the user menu goes is a line of PHP that calls the user template, which isn’t cached. I got that working, but it was clunky and used a lot of space.

With XSL, all we have to do is cache the XML data. It saves hundreds of megs in space for Christian Lyrics and adds a ton of post-processing capabilities, such as adding in the correct user box.

Now I’m going to use a fictional example with some XML and then a little PHP to show how you can use it. It’s the same idea described above, just the XML changed. First is what a cached XML file could look like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<?xml version="1.0"?>
<page>
	<meta>
		<title>My Website</title>
		<description/>
		<keywords/>
		<last-updated>Mon, 15 Aug 05 15:52:01 +0000</last-update>
	</meta>
	<artists>
		<artist/>
		<artist/>
		<artist/>
	</artists>
</page>

So now whenever any visitor loads that page you don’t have to re-process anything, just load the XML and skip your actions. After the XML is loaded you can do any visitor-specific updates to it on the fly.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<?xml version="1.0"?>
<page>
	<meta>
		<title>My Website</title>
		<description/>
		<keywords/>
		<last-updated>Mon, 15 Aug 05 15:52:01 +0000</last-update>
	</meta>
	<artists>
		<artist/>
		<artist/>
		<artist/>
	</artists>
	<user>
		<id>1</id>
		<name>James Logsdon</name>
	</user>
</page>

And then deliver it to the visitor either as raw XML (with a processing directive for the XSL, I hope) or process the XSL server-side and deliver HTML (or whatever you want to transform it into, really).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

<?php
 
// Path to where XML files should be saved
define('PATH_CACHE', './cache/');
 
/**
 * Checks for a cached action XML, if not found runs the action and caches it
 *
 * Usage:
 * // Will cach search action for 1 hour based on the arguments array
 * run_action("search", array(
 *     "query" => "this is a search",
 *     "type"  => "basic"
 * ), 60*60);
 *
 * @author James Logsdon <dwarf@girsbrain.org>
 * @param string $action Name of the action
 * @param array $arguments Arguments that are page specific, to cache seperate results for the same action
 * @param int $ttl Time to live (in seconds) of the cache file. Default is 10 minutes (600). Setting it to 0 disables caching.
 * @return boolean|SimpleXML
 */
function run_action($action, $arguments = array(), $ttl = 600) {
	$filename = $action.'_'.md5(http_build_query($arguments)).'.xml';
	$cache = PATH_CACHE.$filename;
	$xml = null;
 
	// If the cache file doesn't exist or it's too old run the action
	if ($ttl > 0 && is_file($cache) && filemtime($cache) > (time() - $ttl)) {
		$xml = @simplexml_load_file($cache);
	} else {
		//... set xml to SimpleXML in here.
		// Save xml to cache for later (only if cache is enabled)
		if ($ttl > 0) {
			file_put_contents($cache, $xml->asXML());
		}
	}
 
	// Failure importing XML
	if ($xml === false || $xml === null) {
		return false;
	}
	return $xml;
}
 
?>

In the next few weeks I’ll be doing another post on XSL and PHP, I’m just not sure on what part of it yet.

The eXtensible Stylesheet Language (XSL) is a family of transformation languages which allows one to describe how files encoded in the XML standard are to be formatted or transformed. XSL is designed to be data driven and strongly encourages the Inversion of control design pattern. There are three languages in the family:

1. XSL Transformations (XSLT): an XML language for transforming XML documents
2. XSL Formatting Objects (XSL-FO): an XML language for specifying the visual formatting of an XML document
3. the XML Path Language (XPath): a non-XML language used by XSLT, and also available for use in non-XSLT contexts, for addressing the parts of an XML document.

Source: Wikipedia

In a nutshell, XSL can be used to transform a plain XML document into a full-fledged HTML document. One thing I really like about XSL is that the processing can be done either server-side or client-side. Most modern browsers understand XSL and do all the dirty work for you, leaving your server to do other, more important, things. Not only that, but if you send the XML to the client for processing, then you have the base of your API already done.

But the best part is how modular you can make the caching. Here’s how I do it:

1. If the data is cacheable it gets saved to disk in an XML file. Queries are only done to the SQL server for this data if the cache file doesn’t exist or has expired.
2. If it’s not cacheable, insert it into the cached XML document on the fly.

Then the XSL document handles the rest. I can’t think of any simpler way to do it.

However, there are downsides (when aren’t there?):

• IE has notoriously bad support for XSL (of course).
• PHP has XSL support natively in PHP5, but PHP4 requires a PECL library (I can’t find the extension on PECL for some reason).
• More syntax to remember
• The only good documentation I’ve come across is the specification itself. W3Schools, which usually has a pretty decent overview, I found lacking.
• Most variable processing has to be done before you transform the XML. It is possible to use variables in the XSL itself, but it is very limited.
• Javascript does not work on the XML document itself, just the generated source. This means if you use AJAX to grab eg. a list of languages, you have to either do the transformation server-side or in the Javascript itself. Thankfully, Google has an excellent Javascript library to do XSL transformations! Some browsers (Mozilla is one I believe) also have built-in XSLT support in Javascript.
• Unless you do the transformation on the server-side search engine crawlers will not be able to index your site. Of course you could set it up to only transform server-side if a crawler comes.

Now I ask: why don’t more sites use XSL? I know I’ll be building most of my sites in the future with XSL, the benefits far outweigh the downsides in my opinion.

The new admin interface is very nice. Everything you need is easy to get too, and it looks beautiful. I’m getting ready to look at plugins and themes, so there will be changes going through still.