To be clear, the primary use case here is in a case like Etsy, right? This doesn't work so well when we want to have a consistent interface to create HTML, PDF, CSV, XLS, and ODS files, correct?

Presumably DOM manipulation really can't be done beyond applications which are HTML-only in any reasonable sense without getting back to the things you don't like about templating, right?

With good markup semantics and some conversion tools, you probably could generate PDF, CSV, XLS, and ODS from HTML. Some of the more powerful document transformation engines do feats like this.

I don't know, though. I tend to think that this is less a job for the view (and templates) than it is for smart models, or models with some kind of helper that assists them in knowing how to represent themselves in a given format.

Well, the thing is that if your target output isn't HTML, then you wouldn't need to do any DOM manipulation. You'd just output whatever else it is you want to output (JSON, XML, PDF, whatever).

If you had, for example, a bunch of PDF code as a "template PDF" then you might just load that and do string replacement on whatever placeholder text you have in there - but yeah the primary use case I'm thinking of is in implementing web based interfaces.

Sorry einhverfr I can't reply to your comment - but what I think you're talking about is trying to abstract display for HTML, PDF, LaTeX, whatever into a common markup language or template, then repurpose that markup for each output format. Does that sound correct?

So like, you'd want to be able to have something like:

  <article>
        <title><% print article.title %></title>
  </article>

then do something like:

  $tpl->article = fetchSomeArticleFromTheDb()
  $tpl->output('template_name',Format::PDF)

My argument to that would be that there's no realy need for that abstraction - you don't gain anything by it because you have to have some abstracted output engine that is capable of doing that HTML can already do, which is like, HTML :)

Hey, I'd love to continue the discussion, but I think the HN comments are kind of limited in how much they want you to discuss here, feel free to email me [email protected]

EDIT: oops, code formatting

Just to be clear, I am not entirely hostile to the idea here. I just think that there are plenty of cases where generating high quality printed content or the like doesn't work with it and templating is a lot cleaner in those environments. And when your application already requires templating for a reason like that, adding an entirely different way of handling another output format adds needless complexity.

One of the useful applications of dools' ideas is that you could have a mockup which included lorem ipsums or other dummy text. This would make it easier for web developers to test layout.

OTOH, as I say, I am not at all convinced that it is a net win for programs that generate multiple formats of output./

Not really. I will email you though :-)

I will probably post something on the selection and design of our templating system for LedgerSMB in my blog too (http://ledgersmbdev.blogspot.com) by the end of the week.

But then you'd still be back to templating, right?

So if you want a consistent interface, templating is pretty clearly the way to go, correct?