4 ms·

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

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 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/ 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. :)

dools 15y ago
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.
- einhverfr 15y ago
  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?
  - dools 15y ago
    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.
    - einhverfr 15y ago
      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?
    - dools 15y ago
      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

dools 15y ago

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.

einhverfr 15y ago
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?
- dools 15y ago
  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.
  - einhverfr 15y ago
    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?
  - dools 15y ago
    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