On 12/20/06, Martijn Faassen <[EMAIL PROTECTED]> wrote:
Rocky Burt wrote:
> On Wed, 2006-20-12 at 12:52 +0100, Martijn Faassen wrote:
>> http://genshi.edgewall.org
>> Inspired by Kid (in turn among others inspired by ZPT), the main
>> template language of TurboGears, written by the people who also created
>> Trac, and it seems to be getting traction. TurboGears among others is
>> going to adopt it, but also things like the creator of SQLAlchemy (and
>> Myghthy) spending time optimizing it, etc. It's close enough to ZPT to
>> be palatable to me, and has some nice features for reuse.

I both like and dislike ZPT and other such languages these days.
They're great when working on some design-heavy sites. But in other
situations, it's an awful lot of useless typing and structuring.

It matters to me especially when we're talking about reuse. Template
languages differ significantly in their approach. I also prefer to pick
something that has a certain momentum and a certain performance.

If TAL / Page Templates isn't really made available to anyone else,
how could it get momentum? 'zope.tal', 'zope.tales' and
'zope.pagetemplate' could probably be combined into a nice
world-usable egg. With the right extras and entry points, they could
be used with Buffet and then available to TurboGears, Pylons, web.py,

Performance is also a strange game, as template languages differ
significantly in how (or even if) they compile, and how/where they
store that compiled manifestation.

Pylons uses Buffet, or at least a customized version of Buffet,
alongside 'Beaker'. 'Beaker' is a WSGI middleware thing that uses
Myghty's containers (which I guess basically make up the heart of
Myghty's supposedly powerful caching system) to cache templates,
fragments, all in a template-language-neutral way apparently. It would
be nice to be able to use things like that with Zope. Keep TAL, allow
for use of Buffet or something like it (perhaps something using the
same entry point) so that any other supported template language could
be plugged in.


As a side topic, I'm also slowly coming to the conclusion that tales
path expressions are a waste of time and effort. We spent a lot of time
making sure that we can express something as a path expression, and a
Python expression would be just as easy to read and explain. We're not
stopping people from writing more complicated python expressions anyway,
and there are real cases where they're needed. A very different
templating mechanism where there is no Python at all and data is always
pregenerated before rendering is still attractive for other reasons, but
in the ZPT case I've become less and less convinced it's worth the hassle.

The nice thing then about something like Genshi is that instead of:


I can simply write:


Python expressions in TAL are cumbersome in part because they're simply
hard to type, not because they're necessarily *complicated*.

It's not TAL's fault - path expressions are just configured to be the
default for the engine used by Page Templates.

It should certainly possible to set Python Expressions as the default
for your ZPT Page Templates. I did a simple-stupid string template
language that basically looked for the following pattern::

   {{ expr }}

and ran the TALES expression inside. For that setup, I set Python
expressions to be the default. This was used for generating emails,
etc. Kindof a slightly fancy mail merge::

   Dear {{customer.name or 'customer'}},

But I could use string, path, whatever as well.

Doesn't Genshi allow for {{ expr }} type things in its templates? Or
was that Kid? Anyways, I hate having to type a whole bunch of TAL to
generate a fake tag and all of that to do a simple insertion in cases
where I could really do without that overhead::

 <tal:insert content="structure view/featuredFlag" /><br />

'view/featuredFlag' renders lots of fancy HTML on its own, so I don't
need a span or div or anything right there.

Jeff Shell
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to