[ZPT] Any news on Template Style Sheet Language?

[Ian Bicking]

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 
>> statements.
> 
> 
> 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 
manipulating TAL).

>> 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.

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