[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