[ZPT] Any news on Template Style Sheet Language?
Evan Simpson
evan at 4-am.com
Mon Dec 6 15:26:29 EST 2004
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
> statements.
You seem to be arguing implementation details, although I may have lost
sight of your point. TERSE statements *become* normal ZPT constructs,
except in the cases where no equivalent TAL currently exists. For
example, these should behave identically:
ZPT + TERSE:
<p tal:condition="x">
Stuff
</p>
p {
x = options/x;
@tal;
content: x;
}
ZPT:
<p tal:define="x options/x" tal:condition="x" tal:content="x">
Stuff
</p>
> 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'))
statements.append(TAL.content('x'))
...but that hardly seems like an improvement, to me.
Cheers,
Evan @ 4-am
More information about the ZPT
mailing list