Preferred standalone TAL module?

Re: Preferred standalone TAL module?

On Mon, 25 Aug 2003 15:19:52 -0700, Fahd Khan wrote:
[color=blue]
> Going through
> recent postings on Google it seems SimpleTAL is the standalone TAL
> module in most active usage and development just now, would the
> community concur or suggest alternatives?[/color]

Here's another standalone TAL:



but I'm not sure how active it is, and it doesn't seem to support TALES
and METAL.

Van

Re: Preferred standalone TAL module?

Ah I hadn't realized that when people spoke of ZPT they were referring
to a specific package, rather I thought they meant Zope itself. This
will be a good opportunity to see how my current templates and scripts
work when I drop in another implementation.

And seeing as my current application involves analyzing SAS output in
Python, I'll take this as a sign. ;)

Kevin Smith <Kevin.Smith@sa s.com> wrote in message news:<200308260 [email protected] hemorgue.org>.. .[color=blue]
> http://zpt.sf.net uses the actual Zope sources with just a thin wrapper
> around them to make them work outside the Zope framework. They aren't
> currently in development simply because they are up to date with the
> Zope source.
>
> In <5d855b4b.03082 51419.31e894e6@ posting.google. com> Fahd Khan wrote:[color=green]
> > The web-based Python software I've written thus far lacks a consistent
> > approach to generating output. After reading Graham Fawcett's
> > endorsement of Zope Template Pages in the recent web programming
> > thread, I looked up TAL and found it to be quite nice. Going through
> > recent postings on Google it seems SimpleTAL is the standalone TAL
> > module in most active usage and development just now, would the
> > community concur or suggest alternatives?
> >
> > Here's the post I'm referencing:
> > http://groups.google.com/groups?safe...8&oe=UTF-8&as_
> > umsgid=e9570f37 .0304070923.706 [email protected] oogle.com%20&lr =&hl=en
> >
> > 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?
> >
> > Fahd Khan
> >[/color][/color]

Re: Preferred standalone TAL module?

speakstofish@ho tmail.com (Fahd Khan) wrote:[color=blue]
> 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?[/color]

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='ite m 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.pytho n 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