[Web-SIG] HTMLTemplate

[Ian Bicking]

mike bayer wrote:
> referring to this one:
> 
> http://freespace.virgin.net/hamish.sanderson/htmltemplate.html
> 
> it looks very cool and elegant, and clearly produces templates that are
> super-clean.  however, I would wonder how convenient it really is to
> create 100% of all the programmatically generated content in your
> "controller" module, including even the most trivial concatenation of
> strings.  I would think that for a complicated page design with alot of
> data embedded in it, this would lead to a much bigger mess of HTML mixed
> with code in the controller class than the one it seeks to prevent in the
> HTML template.

I imagine myself writing a mini-language in the form of complex id and 
class name conventions to automate this process.

I am using something vaguely similar to this in a project.  Clients 
write HTML using a WYSIWYG editor, and the "template" has conventions 
about what certain tags and classes mean.  Then there's some 
transformations that the template itself can produce.  E.g., we produce 
a table of contents by finding all the h3 tags, and in ZPT it looks like:

<ul>
  <li tal:repeat="item index/h3">
   <a tal:attributes="href item/anchor"
      tal:content="item/content">link</a>
  </li>
</ul>

In this case "index" is a special object (bound to that content), and 
index[tagname] (in TAL this is index/tagname) returns a list of all the 
tags found in that content.  item/anchor return #id, and sets an id on 
the element if one doesn't exist.  And so on.  These little transforming 
objects can strip content out, change classes, etc.

But I definitely wouldn't use this for the entire template.  It's useful 
because the authors really can't be expected to know how to template 
anything, and the in-browser WYSIWYG editor isn't a good environment to 
compose abstract templates.  It works well when contained inside a more 
self-contained templating system like ZPT.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org