On Wed, Dec 17, 2008 at 1:15 PM, Vadim Khaskel <[email protected]> wrote:
> Mario,
>
> thank you for quick response.
>
> I did look into this coockbook page... but this page looked to me outdated.
> For example: config.init_app() call is not in middleware.py, but in
> environment.py
>
> and when I tried to use:
>
> config.add_template_engine("cheetah", "myapp.templates", {})
>
> I got error message that << add_template_engine >> is outdated.
>
> the correct way to use it now - config['buffet.template_engines']
>
> ...so, I just hoped there is a straightforward tutorial on cheetah usage
> with pylons.
>
> thanks again,
>
> Vadim
You're suffering multiple levels of deprecation and a very out-of-date
HOWTO. Also, Cheetah was designed for a very different kind of web
framework, and thus doesn't fit very well with Pylons. I was one of
Cheetah's developers and could explain explain to you why this is, but
it would be a long discussion delving into template caching, search
paths, manually-compiled base templates, Unicode issues, auto-escaping
HTML, dotted template notation, etc. I'd highly recommend Mako
instead, which is based on Cheetah's design but includes recent
techniques for dealing with all these issues. These things can't be
retrofitted into Cheetah without totally restructuring it.
But if you want to use Cheetah anyway, for Pylons 0.9.7rc4 you'd write
a render_cheetah() function similar to render_mako in
pylons.templating. Essentially it would have to calculate the
template path based on the template search path in pylons.config, put
the Pylons globals into a dict (especially including 'c'), instantiate
Cheetah.Template with the template path and search list, call
template.render() and return the result.
For Pylons 0.9.6, just ignore the warning and use whichever way works.
You'll have to upgrade to 0.9.7+ at some point anyway, and you can
implement a better solution then. You'll probably need an empty
__init__.py file in myapp/templates and every subdirectory under it,
and you may need to specify templates as "package.template" instead of
"/directory/filename.html", and you may need to compile the templates
manually before running the application. A lot of this is due to the
fact that the Cheetah-Buffet plugin was the second Buffet plugin to be
written (after the original one for Kid), and it was thought at the
time that a Kid-like API was best.
In either version, if you're using template inheritance (#extends),
you'll definitely have to compile the base templates manually
("cheetah compile") and put them in an importable package. This means
that if you put them under maypp/templates/, you definitely need the
__init__.py files. Cheetah's template inheritance does not use a
search path or compiling templates, it merely imports a precompiled
template module which it assumes exists. Again, this made sense in
the kind of web framework Cheetah was originally designed for.
(WebWare for Python, which was based on the Java servlet pattern.
Precompiled templates were structured so that they could function as
servlets without needing wrappers.)
--
Mike Orr <[email protected]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
