Q: reasonable for novice programmers? A: XSLT (depends); Perl(depends); T::T(good bet).

Q: How is XSLT in practice? A: See below for more info.

Q: Is language-neutrality an XSLT advantage? A: No. Any XSLT 'neutrality gains' are illusory when you consider the differences in parsers (eg XALAN, SAXON, msxsml.dll (various versions), msft "dotNet", perl et al..) and difference in coding styles (which affects every programming language, not just XSLT) and the inevitable "turf battles" and "politics" of it all. Forget "language neutrality", its a marketing phrase. I've used each of the systems you specified, and have (or at least had) a particular affinity for each of them. Here then is one person's opinion.

The short version is this. Avoid XSLT unless you know *exactly* what you're getting into ahead of time. It is not pretty. Use T:T if you have to work with non-technical people on your production team. Use Perl if you have a professional coding style that is eyeball friendly to whomever may inherit your code (thus bypassing the pervasive stigma that some hold against perl). This of course presumes you have no constrains re: technical proficiency; and no vendors or language zealots influencing your decisions.

By the way, the reason all of this is relevant on a perl website is because nearly *every* criticism of XSLT that follows is the diametric opposite of perl. In other words, everywhere XSLT gets it wrong, perl gets it right.

When XSLT (actually XSL) first came out in the last millenium, you might say I was an eager and avid "early adopter". Having had favorable experience with perl templating (and templating tools in general), the assumption was that XSLT would be a versatile transformation and templating system: "just like perl, but with the structure of XML".

That assumption was dead wrong.

Don't get me wrong ... no software is perfect when it first comes out, but the design and direction of XSLT have absolutely convinced me that its principle advocates designers rarely (if ever) actually *use* it themselves for routine tasks. Certainly not as much in comparison to the principle advocates and designers of Perl, or even Template Toolkit for that matter (both of which have advantages and are worth learning).

XSLT "pros"

• XSLT is prevalent, and has the marketing-friendly kewl name that starts with the letter "X"
• XSLT is good if you are selling books, software, certification and courses in XSLT
• XSLT is good if you are a hobbyist who enjoys working with it for its own sake
• XSLT is good if you had a role in designing it
• XSLT is good if it keeps you employed

XSLT "cons"

• "XSLT is not intended as a completely general-purpose ... language" (see http://www.w3.org/TR/xslt) but people use it that way anyhow.
• XSLT appallingly re-invents the wheel for the most rudimentary programming concepts (eg functions, loops, and variables). Moreover, the wheels are *all* square.
• XSLT assumes too much, is too verbose, and too disjointed to be tolerable after the initial novelty wears off, which will be fast, unless you reap one of the "pros".
• XSLT will have you searching for hours on how to do things that the XSLT designers tried to 'over engineer'
• XSLT has too many 'reserved character sequences' that make it a pain to actually write code

For a real-world comparison, here are some snippets of code. DISCLAIMER: These are old code snippets, and may not reflect the optimal way to get the job done. They are just here to give a general idea.

### perl example
print q©
    Hello World!
©for(1..10);
[download]

    [%# Template Toolkit Example %]
    [% FOREACH [ 1 2 3 4 5 6 7 8 9 10 ] %]Hello World!
    [% END %]
[download]

   <!-- XSLT example -->
   <!-- [..snip.. some stuff taken out for brevity] -->
    <xsl:call-template name="SayHelloTenTimes">
     <xsl:with-param name="i">1</xsl:with-param>
     <xsl:with-param name="count">10</xsl:with-param>
    </xsl:call-template>
    <xsl:if test="$i &lt;= $count">
      Hello world!!
    </xsl:if>
    <xsl:if test="$i &lt;= $count">
      <xsl:call-template name="SayHelloTenTimes">
          <xsl:with-param name="i">
              <xsl:value-of select="$i + 1"/>
          </xsl:with-param>
          <xsl:with-param name="count">
              <xsl:value-of select="$count"/>
          </xsl:with-param>
      </xsl:call-template>
    </xsl:if>
   <!-- [..snip..] -->
[download]

MVC is a great model to follow, but I wouldn't want to try to implement it using XSLT, not unless you want to buy my book on how to do it ;-)

You forgot the biggest problem with XSLT. That is, that it is clearly trying to be Lisp (just look at all those brackets!) but without the readability or power of Lisp.

From taking one brief look at some XSLT code at a previous job, I can state with absolute certainty that use of XSLT is always wrong. To parse and run XSLT you need a more capable, easier to use programming language to be available anyway, so why not use it instead.

That is, that it is clearly trying to be Lisp (just look at all those brackets!) but without the readability or power of Lisp.

I think there's a fundamental difference here. LISP looks like that because it has to look like that. It's a direct consequence of being minimalistic and functional. XSLT looks like that because the designers thought that XML is Good. There isn't an underlieing, theoretical reason why XSLT has to be implemented that way, as there is with LISP.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

I am curious - did you touch the problem with the http://www.class-dbi.com/cgi-bin/wiki/index.cgi?CdbiPager not having a method for LIMITing the output from the database? There seems to be a solution on the linked page - but I personally would be scary to use it.

Interesting, but why not Maypole?

Because Maypole has lots of problems that need to be fixed, like:

• abysmal error handling and recovery (mostly inherited from UNIVERSAL::require)
• Bad documentation
• Bad extensibility as soon as more than one object is involved in one action
• Bad logging infrastructure, ranging from nonexisting logging to wildly spewed warnings that can't be disabled
• ...

Many of these things are being worked on, by sri and others, but I wouldn't use Maypole in a setting where there is a client that pays for a working project that goes beyond beerdb in complexity.

The thing I like the least about T::T is that it's slow and bulky - it's great if you want to make a lot of static files from complex templates, but IMO too slow for high-performance dynamic stuff. Also, having a complex templating system will probably bite you if you want to do MVC - programmers will tend to put too much logic in the templates, instead of in the model or controller classes. It's probably better to use a simpler templating system in this case.

As for the controller part, there are modules - most famously the Maypole system and CGI::Application. I personally think that Maypole is doing too much (like Template::Toolkit) and links to too many modules I don't like/want - I'd recommend CGI::Application, it's much simpler and runs anywere.

TT is slow? Compared to what? The only benchmark I know of shows it running at about the same speed as other popular Perl templating tools: http://www.chamas.com/bench/

Snails are still slow, even when you compare them to slugs.

What I dislike about TT isn't TT, but its fanboys. They claim that it allows you to seperate content from presentation from logic and that nothing else in perl does. What rot! Wanna display a table of data? You need logic in the template to loop over the data. Wanna display an arbitrarily sized table with arbitrary headings? You need a *lot* of logic in the template.

The fanboys also argue that TT is easy for non-programmers to use. Sorry, but my experience differs. I wrote some nice functional templates which worked, handed them over to a designer to make pretty (and bear in mind that TT is alledged to be designer-friendly), and he promptly broke them all.

Given that you can't get away from putting logic in the template, why bother inventing a whole new mini-language, when you could just use perl? The fanboys say that that means you put too much code in the template. Not true, unless you're an idiot. Perl has these things called "modules".

Having said all that, I do use TT. For *some* jobs, it's the right tool. For other jobs I use it grudgingly because it's the company standard and it at least has the advantage of being well known.

I've never seen the point of CGI::Application. What, exactly, does it do that a giant if/elsif/else statement doesn't? Nothing, from what I can tell, aside from introducing another dependency, like what you criticise Maypole for.

If offers an easy to understand/use interface for making your controller - and it keeps you from having to write the "giant if/else/elseif" construct yourself.

It's the same reason I use Class::Accessor - it might not be much work to run without it - but it's just really convenient, it's fairly small and it does one thing well.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

CGI::Application does many other things than "a giant if/elsif/else statement" -- and it doesn't even really do that. (It implements a hash-based dispatch table that maps a query string to a method; if no match is found, it uses a default as specified.)

What does CGI::Application do?

• It provides a framework for developing re-usable, customizable application classes. Simply use the class, pass some metadata (in the form of a hash) to the constructor, and run() it
• It provides a sane framework for developing applications; each screen gets a run mode, and each run mode gets a method -- CGI::Application-based classes are incredibly consistent and easy to debug because it's easy to determine what piece of code is executed when (look at the dispatch table instead of trying to scan through "a giant if/elsif/else statement").
• It provides a means for wrapping a number of applications under a site-umbrella, through it's various cgiapp_*() hook methods. Using these, you can create a superclass that does security checks, places final application content in a sitewide template, and creates customized navigation and sidebars -- but still retain the flexibility of developing only a single application suite at a time.
If used correctly, CGI::Application can be used as a very good Controller for an MVC setup -- have it simply do the work of validating and sanitizing input, passing it to the Model, and piping the Model's return values to the View (a templating system).

What I like most about it is that, at it's core, it's a very slim piece of code that simply stays the heck out of my way as I build my applications -- no extraneous doodads or geegaws are loaded unless I specifically do so myself.

Yes, it's another dependency, but it has very little overhead and benefits that outweigh the dependency a thousandfold.

XSLT makes the most sense if your data is in XML to start with. Transforming relational database to XML and then to XHTML with XSLT adds an extra step. But, for example, an aggregator might use XSLT to transform RSS and Atom.

XSL-FO is for printing. Programs like FOP render it into PDF.

I've had some success using Template::Plugin::XML::LibXML for parsing simple XML files. This allows me to process XML using XPath, my favourite part of XSLT, without XSLT's syntax, which I find a little verbose and fiddly. Your tastes may vary, but my point is that XSLT isn't the only templating system that can process XML documents.

It still helps if you learn XPath, which takes time, but provides a very convenient way of accessing data in tree structures.

T::T plays nice with Apache, mod_perl, DBI and MySQL.

From my short encounters with templating systems, I offer you those three terse reviews:

• Template Toolkit sucks. I don't know why other people like it, but they do.
• XSLT sucks even more. It has all the features of Template Toolkit, but you have to write them in verbose XML, without being able to output non-XML.
• I have no experience with XSL-FO, therefore it must suck even more.

If my reviews are too terse for your taste, or you crave other opinions, consider Super Search, which has many discussions of templating systems on this site. Personally, I haven't found a single templating system that suits all my needs, so I switch between HTML::Template, Petal and Template::Toolkit.

Just a nit:

XSLT sucks even more. It has all the features ... without being able to output non-XML.

It's easy (well, easy in XSLT standards {grin}) to output non-XML. Take, for instance, this stylesheet.

-- Douglas Hunter

Not if you want/need control over the whitespace. And if you want to output XML-like, but not XML-compliant structures, like, say, Apache config files, the whole thing becomes even uglier.

I played around with XSLT a little bit some years ago. I found it a painfully verbose language to program in: the extra markup associated with keeping XSLT "legal XML" made the program disappear into the language, so to speak: one twenty-character XML tag starting with "xslt:" looks much the same as another. What really irritated me was that so much of the markup was redundant; maybe purpose-built XSLT editors (or emacs or vim modes) would add that in automatically (someone's already suggested using TT to generate XML).

That's a pity, because XSLT looks like it might be a useful little side-effect-free language. For the moment, though, I'd say that if you desperately want your program to be data, for heaven's sake use Scheme. If I was being paid to produce XSLT code, I'd write a Scheme source filter.

a) They are perl programmers not XSLT "programmers".
b) Perl geeks don't like XML.

Believe some of the hype, not all of it. And believe some of the bad stuff, not all of it.

I've created some very large projects using XSLT and AxKit, and while XSLT isn't the easiest thing in the world, it does have some nice features, such as being declarative (something almost no other perl templating solution achieves well) and being nicely standardised.

There are some comments about non-portability of stylesheets between processors, but assuming you don't use "extensions" then this does not bear out in the real world - stylesheets port very well between platforms.

In closing, my personal opinion is that TT is nice, but is much more of a programming language than XSLT is (despite XSLT offering functions and variables). XSLT is more likely to be understood by future "Design Geeks".

templating systems will never be better than XSLT's for a couple of reasons

it all has to do with language, encoding and xslt scripting /xpath

one of my previous jobs was to make a xml engine for a cell phone game company so the game data could be passed as xml into the engine and translated for the various wap browsers out there.

not only were there xslt's for the phone layout but for the different browser inconsistencies {you think web browsers are bad lol riiight} as well as for different language support {i remember kanji giving us a bit of trouble in this department, but just changing the laguage in the xml header fixed this iirc}

by using xslt includes and imports we were able to eleviate a lot of the programming

sure i love html::template , but it has limitations, and if i needed to provide an industrial strength application i would go xslt's

templating systems will never be better than XSLT

Never? You can't think of any situation where XSLT isn't the right tool for the job?

it all has to do with language, encoding and xslt scripting /xpath

I don't know exactly what you mean here, but Template::Plugin::XML::LibXML and Template::Plugin::XSLT have been mentioned earlier in this discussion, demonstrating that XPath works in non-XSLT environments. Which language and encoding issues does XSLT deal with better than all other templating systems? The latest version of Template Toolkit (2.14) offers improved Unicode support.

I think the point you make with mobile phones is that XSLT can run on the client side, whereas other templating tools can't. I agree this can help in certain situations, but often I prefer to keep the client side as simple as possible, doing complex work on the server environment. As you mention, client side environments differ considerably in their treatment of the same information.