[Zope3-dev] string agnostic page templates, again

[Martijn Faassen]

Shane Hathaway wrote:
> On Wednesday 08 September 2004 09:17 am, Fred Drake wrote:
> 
>>On Wed, 8 Sep 2004 11:02:10 -0400, Stephan Richter
>>
>><srichter at cosmos.phy.tufts.edu> wrote:
>>
>>>Just implement ZPT in C and be finally done with it. :-)
>>
>>Heh.  And just how much of it needs to be in C?
>>
>>Shane wrote a good chunk of it in C once, at the same time we were
>>adding a major feature (i18n, IIRC), and no one stepped up to help
>>test/update that code.  The time available is not unlimited, and a C
>>implementation of something as involved as ZPT isn't trivial.
>  
> It was just a fun experiment, really. :-)  I became a little discouraged about 
> updating it because of the migration to unicode.  <string.h> is an old friend 
> that's hard to part with.

It shouldn't be too hard to support UTF-8, and then convert to Python 
unicode strings on the interface layer with Python. My own fun 
experiment in this department leverages libxml2, so it gains all kinds 
of parser and XML manipulation functionality out of the box. It didn't 
look too daunting, though I haven't really thought through macros or 
i18n yet.

>>I wonder if the best approach would be to implement the evaluation
>>context differently; I remember a lot of the time was being spent
>>there the last time I profiled it, but that wasn't recently.
> 
> In Zope 2, the main bottleneck isn't the TAL interpreter, it's the expression 
> evaluation.  Even simple TALES expressions in Zope 2 are fairly expensive.  I 
> don't yet know how Zope 3 compares.

I figured that would be the case. An approach to page templates where a 
lot of pre-processing takes place in the view, delivering dictionaries 
and the like to be used from Python, could help here. This would also 
help with separation of concerns between programmer and template 
designer. A bug in the underlying methods called in such a design would 
not bite the template designer so often, as it would usually already be 
evident that the data the view producing is bad, instead of showing the 
template designer some wild traceback.

This separation of concerns is similar to XSLT-based templating systems, 
where the input data is XML produced by some earlier stage of 
processing. Any errors during that earlier stage will more likely be 
detected by the programmer, and the template designer has a relatively 
well define XML structure to work with.

Anyway, if you have such a separation of concerns and simple 
datastructures on the input side, optimizing the expression evaluation 
would be more doable, at least for expression languages that are simple 
enough, such as the path expressions. I imagine a system like libxslt is 
so fast in part because many forms of simple xpath expressions common in 
stylesheets can be executed very quickly.

Regards,

Martijn