Mike Orr wrote:
Having minimal Cheetah integration so you can at least use a .tmpl
file for output seems like a good start. This will pacify the large
number of people who will not use TG without Cheetah. No, it's not
about "market share". It's about using the best tool for the job, and
if we think TG is the best framework for many jobs, we shouldn't
arbitrarily hinder people from using it just because we're dogmatic
about templating. Maybe they'll warm up to Kid gradually if it's not
shoved down their throat at the beginning.
+1
I think TG should continue using kid as it's "native" template language
(ie. widgets, i18n, etc...) but support cheetah as it currently does for
easy migration of other subway/cherrypy sites and having an alternative
for jobs where it performs better or it's easier to set up..
I'm currently working on a site and using cheetah for mail and system
configuation templates. (generating Bind zone files, Apache vhost config
files, etc...). It used to be only cheetah based (via, now obsolte,
http://trac.turbogears.org/turbogears/ticket/214 hack that i wrote), but
it's been quite easy to port all form-generating templates to kid for
integration with the widgets/fastdata subsystem.
I really think TG must still support cheetah, and other template
languages that people care to implement as plugins (BTW, thanks kevin
for the cheetah plugin, it's feels much better not branching too much
from the trunk by using my ugly patch). Mainly because they're not too
hard to implement and can only be good. Anyway, Kid should continue as
"official" main language for core functionality (widgets et al.).
It's easy to have a mixed templating system running (i do), just make
sure you stick with kid if youre using widgets or i18n in the template.
(I believe that if you "render" the widget instead of "insert" it you
can still have widgets in a cheetah template, though no automatic
insertion of css/js in the <head> will take place)
As Mike said: "It's about using the best tool for the job"
Alberto.
