Search

We’ve had some interesting debate going on about the world of templates, JSON, XML, and XSLT. Everyone agrees that the power of XSLT is part of what makes Symphony great — so help us explain why it’s great! Here’s some food for thought:

  • Why do you find XSLT enjoyable to use?
  • What can you do with Symphony’s XML/XSLT layer that you can’t do elsewhere?
  • What powerful capabilities have you discovered?

This should be fun. There’s probably tons of things I enjoy about XSLT, but here’s some from the top of my head right now:

  • It encourages and makes it easy to create self contained smaller templates for part of your dataset, which enables reuse while still being able to override locally.
  • It makes recursion on a nested dataset (e.g. navigation) very easy and natural; write one small template and you can create an infinite depth menu etc.
  • It blens in nicely with the syntax of HTML

And that’s without getting started on XPath which is kind of like regexp for XML. The basics gets you along well, but when you dig a bit deeper and learn about axes and expressions you have a really powerful tool for filtering, grouping etc. on your dataset.

As a designer, I was able to pick up pretty fast how to learn it because it was pretty similar to HTML. I also like that I could learn it quickly using in a similar way to the Wordpress loop, and then later dive in more to the templates and more complex stuff. Still figuring some of that out.

I like XSLT for the following reasons:

  • It’s fast: Because it’s not a scripted template-language which is interpreted by a scripting language like PHP, but rather a compiled library, the parsing of the templates is extremely fast. So fast, that in most cases you don’t even need to cache your pages.
  • It’s clean: Since the syntax is XML-based, just like HTML, it integrates nicely with your templates. Also, I like it so much that the generated output is nicely indented and comments are stripped out. Since of it’s strict approach, you’re (almost) always sure that your pages will validate nicely.
  • It’s versatile: Creating master templates, creating placeholder templates, it allows the use of re-usable templates (utilities); all of this with only a very basic core to start with. Combine that with extensions such as EXSLT for example, and it makes XSLT a very powerfull template language!
  • And last but not least: It makes me want to wear this t-shirt.

Before I found Symphony, I created a templating system solely using XML and XSLT, no php involved. I thought to myself: Self, this is the best templating system you’ve ever used, and there are still plenty of ways you could refine it. You haven’t even touched a server-side language either. This is perfect: a content management system that JUST manages content, no frilly, silly templating language to learn, no system trying to do more than what content management systems do, you know, manage content. Now, I’m not sure I’m going to be a purist and say that a server-side language shouldn’t touch templating, because all objects are neutral meaning they aren’t inherently good or evil. How we use them judges so, but XSLT is definitely powerful anyway you slice it.

As a side note, this got me thinking we should start a website dedicated to it. Unfortunately, someone already snagged http://ilovexslt.net/. That being said, ilovexslt.com is still open… I’m thinking seriously here, now. Anyone want to brainstorm up an idea for the website content? I’d love to pay the hosting and domain registration costs if someone can think of a good idea.

An XSLT website is already in the works, actually! If you’re interested in helping out, email craig@ this website.

What I love about XSLT (+ Symphony) is that it empowers me as a web designer to develop almost anything that I can dream up without having to understand the inner workings of a server-side scripting language. I am so perplexed by the resistance I find to XSLT everywhere I go. Even the Standardistas, who talk about all the wonderful things about HTML5 and CSS3, practically roll their eyes if you mention XSLT.

I think it will take a Zeldman associate writing another book, XSLT for Web Designers, as an addition to the latest publishing efforts of A List Apart, to do for XSLT what Zeldman and company did for CSS.

Is Allen Chang the Eric Meyer of XSLT? ;-)

No, Eric Meyer is the Allen Chang of CSS. :D

No, Eric Meyer is the Allen Chang of CSS. :D

lol :D

It would be pretty interesting if we could do something like a CSS Zen Garden by having a common XML document that people could use as a basis for submitting XSLT and CSS to transform into a bunch of different designs: XSLT Zen Garden.

XSLT Zen Garden.

XSLT Zheng Garden!

@eKoeS: Nice! :D

a common XML document that people could use as a basis for submitting XSLT and CSS to transform into a bunch of different designs: XSLT Zen Garden.

I really, really like that idea.

Edited my post to get back on topic

I am so perplexed by the resistance I find to XSLT everywhere I go.

Maybe, while compiling a list of all the things we love about XSLT, we should also compile a list of all the reasons people give for disliking it.

Maybe, while compiling a list of all the things we love about XSLT, we should also compile a list of all the reasons people give for disliking it.

I’d be interested to know that, as I agree with @bauhouse with this:

What I love about XSLT (+ Symphony) is that it empowers me as a web designer to develop almost anything that I can dream up without having to understand the inner workings of a server-side scripting language.

XSLT is almost like HTML markup, which I do a lot of. This makes it feel easier to learn in a way! I know the very basics of PHP, which couldn’t accomplish much, but knowing the basics of XSLT, I can do a lot more - especially combined with Symphony.

Maybe, while compiling a list of all the things we love about XSLT, we should also compile a list of all the reasons people give for disliking it.

That should be pretty easy:

  • It’s “dead” and/or XML is dead
  • “Enterprise-y”
  • Verbose / hard to read
  • Incurs a performance penalty compared to using only your server-side language of choice
  • Declarative programming, which most developers aren’t as familiar with / don’t understand
  • Variable handling seems clunky compared to imperative languages

I’ve seen it mentioned on the web before, but I wonder what a shortened syntax would do for XSLT adoption (akin to jQuery’s DOM selection advantages over plain Javascript.)

Good list, jonasd.

I’ve seen the “verbose” argument a lot, and I don’t completely buy it. First of all, don’t developers use good code editors? Secondly, if people likes terseness that much maybe they’d like a regexp-like templating language?

Then there’s also the hidden benefits where some things just requires less effort (and probably code) to solve in XSLT. For example adding extra attributes conditionally to an element often requires duplicated code or very ugly inline code inside the start tag in other templating languages. XSLT makes it very easy to read with separate and or .

Regarding “it’s old/dead”, I liked the comparison someone here on the Symphony forum made to XmlHttpRequest which is so modern and popular now (well, WebSockets may steal the stage soon), but originally quite old.

I’ve seen the “verbose” argument a lot, and I don’t completely buy it.

It may be pedantic, but I think there is an argument to be made. For example, an if statement in XSLT:

<xsl:if test="price &gt; 10"> Woot </xsl:if>

compare with ExpressionEngine template tags:

{if price > 10} Woot {/if}

clearly there is more chatter in the XSLT version. Another example, retrieving variables in XSLT:

<xsl:value-of select="$website-name"/>

versus EE:

{site_name}

of course you can also do {$website_name} in some contexts in XSLT too, but these are just examples to prove the point.

I don’t think this is that big of a problem, but programmers tend to want the least amount of typing to accomplish a task, so I can see why it would be a turn-off.

That should be pretty easy: […]

I would add “scarcity of online resources, guides and tutorials”, apart from W3 Schools and xml.com. That’s why I like the idea of a XSLT Zen Garden to promote it. ;)

That should be pretty easy: […]

Two words: string handling

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details