I've being working on integrating Balazs Ree's CTAL interpreter recently (added tests, fixes, etc.). CTAL is the equivalent of TAL but for javascript. For the record MochiKit also has something equivalent called "MochiTAL" that supports "tal:content" and "tal:repeat".

Anyway, CTAL implements all familiar instructions (tal:repeat, tal:condition, tal:omit-tag, tal:replace, tal:attributes) except one which is ... tal:define. There is also the equivalent of "python:..." which naturally becomes "javascript:..."

I almost felt that something was missing, because I'm so used to inserting "tal:define" in page templates. But now I realize that this is a mistake.

There was a discussion recently on the list about python expressions being a bad idea, think twice I would say that "tal:define" is much worse:

When writing templates, the temptation is great to insert a "tal:define" to pull some data into the view which is not directly available in the model represented by the view. But the idea with a template is that it should represent some data using some markup. The data is supposed to be already available in some context. If the presentation layer needs to cook some extra data, it means that there isn't enough presentation data in the first place.

Also in a situation where serveral views observe the same model, all views must have access to the same information. A view cannot hold a private data layer.

Some argued that python expressions in ZPT are bad. Why are they? If there is no "tal:define" to put the expressions into what can go wrong?

The question about separating presentation from data has nothing to do with *how you access the data* ( via tal:content="item/url" or via tal:content="python: item['url']" ) it has to do with *where you put the data*.

here is the test file to get an idea of what CTAL can do:


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

Reply via email to