Preferred standalone TAL module?

[poiboy]

speakstofish at hotmail.com (Fahd Khan) wrote:
> I'm also motivated by the web programming thread's underlying message
> of seeking "industrial strength" solutions that work in many domains
> using existing tools, so that I spend more time coding and less time
> "shopping" for modules. TAL seems a good way to do that (I'm most
> certainly not ready to take the plunge into Zope). Any comments there?

My TAL-fu seasoning consists of a whopping two websites, the first
done in Zope (ZPT) and the second with mod_python (SimpleTAL). But
with little reservation, I don't plan on looking much further than TAL
in the near future:

* Plain HTML is editor highlighting- and indenting-friendly.
* Both the logic and presentation code is concise. Ex: Lists are
  rendered with a single "embedded" tal:repeat='item list' attribute.
  (I'd like to see how thin I can make code that glues
  database-enforced values to a TAL page.)
* Eliminating HTML<->template translation overhead speeds up everything
  considerably.
* TAL works with Zope & Python (all 31 flavors), PHP, and Java -
  though this is more for the PHP and Java crowd since I can't imagine
  a Python slithering backward.

Counterpoint? In an attempt to sound objective, here's one: debugging
*may be* a pain. However, in practice it seems that the easier a
templating system is to debug, the less it looks like a (um,)
template. TAL at least encourages an implicit "print" based solution -
with a template full of dummy text and images, it's rather obvious
where errors in logic are occurring (with the obligatory edit, save, 
refresh). Meanwhile, finding an error in template processing is as
hard as tracking down the missing '}' in any other language.

Things I woke up to on this last project: comp.lang.python threads
dealing with web programming are often filled with tips like
"just do it yourself" or "it's somewhere in Webware or Twisted" - all
of which sound(ed) pretty vacuous to a PHP person (moi) looking for
session_start() or $_GET equivalents. Turns out that it was easier
to dismiss those tips than to put real thought into what "doing it
myself" really meant. Looking up from the relatively low-level
mod_python, I don't see any difficulty now in quitting PHP cold turkey
(excepting webhost variety). And by confining mod_python-specific code
to a couple of files, it'll be easy to port the bulk of this or any
future website to Webware (when growth warrants the investment in
education) or Twisted (when faced with the inevitable transition from
website to real-time multiplayer extravaganza).

Best to you,
the poiboy