| XSLT - Universal Web Template Language in Waiting |  |
XSLT – Universal Web Template Language in Waiting
Earlier this year Anup Shah of OneNought.com wrote a brilliant blog titled “Why Use XSLT in Server Side Web Frameworks For Output Generation?” This is a great question and in this week’s blog I would like to add to the comments that Anup has made on this subject.
It’s time for framework developers to start taking the problem of HTML templates seriously. I don’t believe that back-end developers place enough importance or time and effort on HTML templates. In some frameworks they appear to be an afterthought, and are often just mash-ups of the developer’s language of choice and HTML.
A good HTML template language should be an open standard
I cannot think of any other template language that is a W3C standard apart from XSLT. What I love most about open standards is that they bring developers together. HTML is an open standard, and for reasons that I go into further below, any HTML template language should be as well.
A good HTML template language should be platform / language / framework agnostic
Platforms, languages and frameworks require an emotional investment by their users. “We love platform X because it is so easy to use” and so on. The aim of an HTML (web) developer is to write code oblivious of platforms, languages and frameworks. Back-end programmers must choose platforms and frameworks based on what is going to be the best solution for the problem at hand. But HTML developers should be able to tag along with that decision without having to re-skill or even consider the choice at all.
A good HTML template language should be portable
“What happens if your company goes under?”
“What happens if for one reason or another we decide we don’t want to use your company anymore?”
“What happens if our business outgrows Framework X and we need to use Framework Y?”
IT managers ask these sorts of questions all the time. If your framework uses a proprietary template language it means that when the client decides to upgrade their site, they are going to have to throw away work that they have paid for. This is not acceptable to most IT managers once they are made aware of these consequences.
A good HTML template language should work just like HTML
Notice that I have not said “should be easy to use”. Many programmers complain that XSLT is difficult to use. That may be true, but simple XSLT it is no more difficult to use than XHTML, and web developers have mastered that language and enjoy it. Furthermore, XHTML and XSLT both come from the same parent: XML. A simple XSLT template is semantically the same the XHTML it produces which makes it easy for web developers to learn.
XHTML and XSLT often have to be coded by hand to be optimised for the web and to acheive web standards compliance. Attempts at WYSIWYG editors have been a disaster and I cannot see a solution to this any time soon. Personally I enjoy coding HTML and XSLT by hand and find that method faster and more productive than using a WYSIWYG editor and cleaning up the code that it produces.
A good HTML template language should be extensible
I mean truly extensible. This term is thrown around a lot by CMS frameworks, but most proprietary template languages will run out of options for extensibility sooner or later. What I dislike about proprietary, non-standard template languages is that it is like a developer woke up one morning and thought, “you know what? I think I’ll write a template language.”
What I love about XML/XSLT is that for decades now, the best brains in the world have collaborated, designed, debated, and approved a truly brilliant standard. It is extensible and therefore extremely versatile.
We use XSLT for emails (plaintext and html), generating CSVs, JavaScript and PDFs. I have used XSLT to transform XML into a proprietary label printer language for printing shoebox labels in a warehouse. And the beauty of XSLT is that it is intelligent enough to choose its own output type based on parameters passed to it, i.e. you can support multiple output types in the same template. This functionality is built-in to XSLT.
Summary
We have been using XSLT as the template language for the Klixo CMS for almost 5 years now and find it to be powerful, extensible and versatile. I train developers in XSLT without any problems; they have all grown to love it. Like most languages you can start with a very simple implementation that will get you by for most jobs, before digging deeper to explore the real power of the language.
We are currently working on an upgrade to our CMS software that will change the underlying data model quite drastically. Upgrading customers to the new model is not a problem because we can translate from the old schema to new using, you guessed it, XSLT. This means we don’t have to force our customers down a costly upgrade path to take advantage of new technology.
While we do provide template development in-house, our clients have the option of outsourcing template development to a third party because we are using an open-standard. This is a unique selling point for our software that wins us sales over our competitors, not because we have a proprietary system that is perceived to be better than others, but ironically because we are embracing open standards that our competitors do not.
In a way it would be easier and better in the long run if our competitors were using XSLT, because it would give our customers more options and make it less expensive for them to switch providers, based on the need of their organization at the time. At the end of the day, what is best for our customers is best for us!
 |
