Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've been thinking about some of the ideas in this rant for a while now. I might not have put it in quite such an opinionated manner (templating systems aren't usually my biggest problem), but I pretty much agree with a few things:

1) Fragmentation is a problem, particularly with some templating systems. Layouts should almost always be a single file. Things going inside the layout should probably be single files.

2) As long as templating means sprinkling extra tokens to process throughout a document, there's going to be some coupling problems. Transforming a document based on some external criteria is an interesting alternative.

There's certainly a number of transformation based solutions out there, some of them pretty powerful. But as I was thinking about this a few years ago, it occurred to me that maybe I don't want a powerful uber-transform set so much as I want a simple descriptive set of semantics for addressing content into nodes of a document.

Then I thought about where I'd seen this kind of thing come up before in the realm of document styling: DSSSL and XSLT vs CSS. The simple descriptive CSS won out and has worked out more or less well.

So... I came up with something I called `CAST` (Content-addressed Style Templating):

http://weston.canncentral.org/web_lab/CAST/about.html

Basically, you use a subset of CSS selectors (or XPath queries) to pick out a node of a document, then you specify a content rule, and the engine drops a content string into the document node.

I ended up writing my blog around the idea. I ended up being pretty happy with a very simple set of rules, despite the fact that there's not much too the system beyond that -- for example, there are no rules for conditionally hiding a node based on whether or not it's needed, no rules for repeating certain nodes. I think those things might be nice, but it turned out if I was willing to push a little bit of the view down into model layer, I didn't need them at all, and I was (I kindof tend to think that any application is going to have a bit of model-view bleed-across anyway, you just have to figure out how you'd like to manage it).

If anybody's curious, this post made me get off my behind and put the code up on GitHub:

https://github.com/westonc/CAST/

But it's in PHP, which I suppose will probably turn off a lot of the cool kids, so I should probably write a Ruby or Clojure version. :)



Yep this is pretty much the idea. The key thing is, though: however you do it on the backend, that's entirely a coding problem. DOM manipulation sucks? Well, solve that problem, which is where something like your CAST library comes in.

It's easier to solve the problem of making a nice, easy way to "address" content (I used "animate" but basically they're the same thing :) than it is to solve the multitude of problems caused by choosing a technology stack and creating templates in it for your application.


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 iain@workingsoftware.com.au

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?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: