It's a lot looser than knowing the whole DOM. You just need to know
the IDs. And in some cases, only when an id is used in multiple
places, you will need to know the id of its parent. That's the only
mental model you need. You don't need to have any idea what
the tags are or how the page structure is arranged.
Okay, so say the template designer has a big <div id="documentBody"> where
I am to put the document body. There is a different way of displaying that
for each content type. Inside that, I need, say, an <h1>, a couple of
<div>s and whole bunch of structural content for the actual document body.
Do I output those variable elements with python with print statements?
To be honest, I think I'm just a little uncomfortable with the
"procedural" approach to templating, It seems a little poorly structured
and prone to error, e.g. if I'd have to manipulate things in loops etc.
Basically, instead of relying on syntax (e.g. TAL) that lets me declare
what I want (put X here, loop over these), I'd have to rely on patterns
and APIs in a fully-featured programming language. It seems a bit easy to
miss a tag or treat something as iterable when it wasn't meant to.
To that extent, I prefer the separation of concerns in a scenario with
Five views (i.e. view classes bound to logic, individually unit testable,
well-defined boundary between view logic and presentation) and TAL
expressions only. And again, for the "site themer" role, a layer on top of
that like what Paul is describing sounds appealing.
(then again, I spent today learning Tiles, and either alternative is
better than that ;-)
That's not to say your work isn't intriguing though. I reserve the right
to become convinced. :-)
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests