[ZPT] Any news on Template Style Sheet Language?

[Ian Bicking]

Evan Simpson wrote:
> Ian Bicking wrote:
> 
>> Interesting, I hadn't seen that before.  I'm not sure if it's playing
>>  the role of an XSLT-type transformation, or... what exactly.  I feel
>>  like it should fit into some already-existing templating style, but
>> I can't determine exactly what.
> 
> 
> I doubt it fits.  TERSE allows you to express the sorts of tag-scoped
> operations that TAL supports, but using CSS-style pattern matching.  It
> is slightly similar in function to XSLT, but only slightly.
> 
>> Part of what confuses me about it is that it seems to apply both
>> before normal ZPT substitution, and after.  There's something
>> DOM-like about it, for these seem similar:
>>
>> img#portal { [src] = "$base/${attrs/src}"; }
>>
>> and:
>>
>> document.getElementById('portal').setAttribute( 'src', '%s/%s' %
>> (base, attrs.src))
> 
> 
> Here's the semantic model that I use: First, the document is searched
> for matches to TERSE rules.  Next, the rules are "attached" to the
> matched nodes, mixing them in a deterministic way with TAL statements 
> found on the same node. Finally, the template is rendered in the same 
> fashion as a TAL-only ZPT, except that there are additional statements 
> to execute along the way.
> 
> It takes a bit of getting used to, but the model is *quite* different
> from manipulate-the-DOM approaches.

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.

>> This leads to the question -- which is a more accessible way to
>> approach these modifications, from Python or form a stylesheet?  I
>> think there are valid reasons for these kinds of transformations.
>> The pluses and minuses are the same as for any domain-specific
>> language, I think; because you are working before ZPT comes into
>> play, these transformations really implement a kind of language, for
>> better or worse.
> 
> 
> One large practical advantage that the ruleset approach has over DOM
> manipulation is this: you can combine a template and a ruleset into a 
> "compiled" representation (TAL-like bytecode) that can then be rendered 
> effeciently with different data sets.  Typical DOM code, on the other 
> hand, must repeatedly search and transform the document's tree each time 
> that it is run.

Well, potentially; you could also save the DOM just like you save the 
TERSE compiled form.  In that case, though, the DOM would have to work 
less concretely on the source, creating expressions meant for future 
evaluation instead of directly manipulating the structure.  So, taking 
the last example:

els = document.getElementsByClass('item-list')
for el in els:
     el.zptOverride = ItemSubber(el)

class ItemSubber:
     def __init__(self, el): self.el = el

     def enter(self, namespace):
         items = tal_eval(namespace, self.el.getAttribute('items'))
         if not items:
             new = el.document.createElement('b')
             new.appendChild(el.document.createTextNode('No items'))
             el.parentNode.replaceChild(new, el)
         else:
             namespace['items'] = items

     def exit(self, namespace):
         try:
             del namespace['items']
         except KeyError: pass

Then ZPT looks for the zptOverride attribute, and calls enter and exit 
functions, or something like that.  This starts getting annoying to 
express with the DOM, but one can imagine helper classes and functions 
to make this more pleasant to work with.  Or, for that matter, you could 
create these transformations from TERSE source.  It's got to turn into 
Python at some point, after all.

> I also believe that rulesets are more "granular" than DOM code.  It is 
> straightforward to add or modify rules in a ruleset, or to combine 
> independently created rulesets.

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?)

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org