Author Archive > james

The Power of XSL

James » 22 February 2008 » In Code » No Comments

When we did the last rewrite of Christian Lyrics I spent a good bit of time working on the template system. I loathe Smarty due to how bloated it is, but almost went with it because needed modular caching (guests all see the same static files, logged in users see their user info, etc…). We ended up using a Savant style system (no stupid custom tags, no parsing, just PHP) that works pretty well, but has some short comings still. After we finished the rewrite, I spent some time exploring other options. Only one caught my eye: XSL.

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.

Update: I completely forgot to mention a very important downside. I bolded it in the list.

Continue reading...