ianb at colorstudy.com
Fri Jun 3 00:58:11 CEST 2005
mike bayer wrote:
> referring to this one:
> 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:
<li tal:repeat="item index/h3">
<a tal:attributes="href item/anchor"
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
More information about the Web-SIG