Original data sources are a mix of ICAO, Met Office, FAA and US DOD data feeds – parsed using perl Lexers and stored in a database as plain text, then pulled out as objects with validation and other methods (such as providing lat/lon, dates and other properties).

My templating system (http://www.tt2.org) allows me to provide arbitary data structures, including iterators of these objects to the templates, as well as direct access to classes for class methods, the ability to call object methods, etc.

The templating system also provides dozens of built-in filters and hundreds of extensions to make it simple. All of which is heavily tested and proven to work when it matters.

Writing custom XSLT would not only be a poor use of my time, but introduce the risk of errors and require further unit and regression tests. Changes would also be slower than modifying templates, and with only 2 main templates (or even dozens) for a particular report ‘perl -pie’ allows me to search and replace in an instant.

Templates are also accessible to designers, and easier to track changes in. XSLT is just lose/lose : slower and more error prone both in development and at run time.

In terms of a report – HTML is content marked up for semantic organisation and basic layout, with CSS providing styling.

XSLT *is* error-prone at runtime – syntax/parsing aren’t the only errors – logical errors are not only harder to spot, but harder to avoid and fix. XSLT makes a problem bigger by providing another layer of complexity and escaping troublesome characters.

As I’ve said templating works far better for most jobs, a well-formed and valid template won’t stop working or suddenly become invalid, or be thrown by unescaped or double escaped content and can even handle it well.

I can generate valid XML/HTML/ODF, or create it manually, either way – I still use it as a template and XSLT doesn’t provide any benefits.

The telling point in your argument, from my POV, is that you say XSLT is error-prone at runtime. It’s not. As long as your input is a tree document, your output will be too. If your input is text that kinda sorta looks a little like a representation of a structured document but only does so because you’ve cleverly remembered never to put a slash-foo before a foo or leave an attribute unquoted, THEN you’re going to run into problems.

Again I say: the right tool for the job is XSLT, or anything else that works with the DOM. Everything else is what I call Programming By Puns: it looks right, but it’s not really.

Essentially you’re suggesting I use XSLT for templating, which is a bad idea – particularly for automated reports. XSLT is nice for stylising, but not for nontrivial templating. Not only does it require a great deal more work up front, but it’s slower and more error-prone at runtime.

I have 2 templates, using a far better templating solution than XSLT, one for ODF one for HTML, both very different, if I need to change some of the small ammount of non-generated text, that is both rare and simple.

XSLT is good if you don’t have a decent templating system, or need simple restyling or formatting of XML, but for 99% of problems you’re better of with a tool designed for the job.

So instead you edit the static parts of your site as XHTML in XML documents. You generate dynamic output at the server side as XML. If you must produce HTML at the client side, you do so using the DOM, but that’s outside the scope of this. The goal is to push everything through an XSLT template that slurps in the appropriate content and adds all your navigation and headers and footers (or RSS stuff, or whatever).

How many XHTML-like views are you providing?

Surely CSS and (X)HTML is sufficient – XSLT seems an un-necessary addition given that HTML, RSS and REST, etc will all contain different content anyway.

I don’t use Mason, I use Template Toolkit, I’ve never needed or wanted XSLT yet – the only project where I’ve seen it required was a major document management system for a national standards body (using the Maypole Perl MVC framework).

Apart from that, I’m in complete agreement. Monochrome source code is the only way to go!

I have been making stabs at using CGI::Application and Catalyst, but so far not much traction. I look forward to exploring your MiniMVC work!