[ZPT] Any news on Template Style Sheet Language?
ianb at colorstudy.com
Mon Dec 6 15:59:05 EST 2004
Evan Simpson wrote:
> Ian Bicking wrote:
>> I'm still not seeing it. Besides being more convenient and whatnot,
>> which isn't exactly fundamental.
>> For both TERSE and DOM, ZPT must work on some well-defined
>> representation of HTML/XML source, not just text, and not just an
>> internal data structure. In that, I believe both cases require
>> attaching data that can't necessarily be serialized back into HTML.
>> Well, one difference might be that TERSE gets evaluated lazily (?);
>> before normal ZPT constructs, but just barely. At least that's how
>> I'm interpreting what you call mixing rules deterministically with TAL
> You seem to be arguing implementation details, although I may have lost
> sight of your point.
I don't know if I actually have a point. I'm not anti-TERSE or
anything. I'm trying to understand what TERSE accomplishes, and if
there's a way to accomplish the same thing through Python instead of
introducing another language to the mix. And/or to understand the TERSE
through understanding its execution, which gets into implementation.
Since TERSE is a new language that integrates with an existing language
(a couple existing languages, actually), the implementation is very
important. There's a lot of subtle and potentially problematic
interferences between all those languages (TERSE being added to TALES,
TAL, METAL, and Python; building on TALES and Python, and directly
>> I think the CSS-like selectors encourage a more granular way of
>> looking at the problem. It could be implemented the same way with the
>> DOM, including composability, but there'd be less implicit guidance
>> towards that style. Of course, if the DOM included methods that were
>> equivalent to CSS selectors, that'd help a great deal. (And why
>> doesn't it?)
> Once you've got all of the necessary framework in place, you could
> certainly write a python function that matched the TERSE above, such as:
> for el in document.bySelector('p'):
> statements = el.getTAL()
> statements.insert(0, TAL.define('x options/x'))
> ...but that hardly seems like an improvement, to me.
Certainly working on a source level -- that is, adding string values to
attributes which will then be parsed and evaluated -- isn't a good way
to build this. Which is why I'd rather add objects to the document with
enter/exit methods, or some other technique. I don't know a lot about
the internals of TAL, so maybe it's a lot more expedient to work on the
source directly. Though it's probably not too hard to do it with
lower-level (post-parse) data structures.
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the ZPT