7 messages in com.googlegroups.pylons-discussRe: turbocheetah| From | Sent On | Attachments |
|---|---|---|
| Jose Galvez | 22 Jun 2006 11:25 | |
| Ben Bangert | 22 Jun 2006 12:13 | |
| Jose Galvez | 22 Jun 2006 12:51 | |
| Jose Galvez | 22 Jun 2006 14:47 | |
| Kevin Dangoor | 23 Jun 2006 05:02 | |
| Jose Galvez | 23 Jun 2006 08:32 | |
| Kevin Dangoor | 23 Jun 2006 08:39 |
| Subject: | Re: turbocheetah![]() |
|---|---|
| From: | Ben Bangert (be...@groovie.org) |
| Date: | 06/22/2006 12:13:45 PM |
| List: | com.googlegroups.pylons-discuss |
On Jun 22, 2006, at 11:26 AM, Jose Galvez wrote:
Not sure if this is the right place to ask, but its a good place to start. I've been experimenting with pylons quite a bit lately, however i really like cheetah as my template engine. Is there any way to use turbocheetah with templates written with an alternate extension rather then the default tmpl? I usually user html becasue it keep dreamweaver happy. Any thoughts?
This is actually part of why I needed to make a custom version of Buffet and BuffetMyghty instead of using them directly. BuffetMyghty worked only with .myt files and Buffet was bound to CherryPy. This is mainly because the TurboGears Template API being used is done with the assumption that every Template Plug-In shall handle a specific extension, and that the template name reflects a Python style import path (how Kid works).
This frequently conflicts with template engines which can handle rendering many types of extensions and in fact commonly do. The TG Plug-in model more or less starts with Kid's style and tries to twist all other template engines to work the same way. To alleviate this condition and move towards a more interoperable plug-in style, Kevin started a pytemplate list on Google aimed at coming up with a replacement scheme that will let template plug-in's handle the rendering and style themselves.
Unfortunately this effort seems to be stalled right now, though Ian did put up a reference implementation. I'd be interested in continuing this and using the pytemplate API, though we need to come up with some scheme to at least decide when we'll "commit" to using it. Having TG commit to it would be an excellent first step as that'd accelerate the development of pytemplate API compatible plug-in's.
In the mean-time, other than making your own version of the TurboCheetah plugin that retains the extension you supply, there's no current way to render Cheetah templates deviating from its scheme. If you'd like to do that (its a pretty simple API), I'd suggest taking a look at my customized version of BuffetMyghty and adapting TurboCheetah to use the full template name that comes in as well.
I've already committed a change so that template engine's whose name starts with 'pylons' will not have the template name altered at all, that way the template plug-in will be able to get the full path as it was provided. Here's the custom BuffetMyghty I wrote: http://pylonshq.com/project/pylonshq/browser/Pylons/trunk/pylons/ templating.py#L186
HTH, Ben
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylo...@googlegroups.com
To unsubscribe from this group, send email to
pylo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss
-~----------~----~----~----~------~----~------~--~---




