On 4/4/07, askel <[EMAIL PROTECTED]> wrote:
>
>
>
> On Apr 4, 1:29 am, "Mike Orr" <[EMAIL PROTECTED]> wrote:
> > I tried incorporating TurboCheetah into Cheetah and (re)discovered
> > it's using dotted notation ("section.index") rather than the URI
> > notation ("/section/index.tmpl") that Pylons at least is standardizing
> > on. I'm hesitant to put dotted notation into Cheetah, yet I'm not
> > excited about rewriting TurboCheetah either, and I'm also concerned
> > about breaking existing TurboGears sites if I add an entry point into
> > Cheetah. So I thought I'd ask:
>
> it is because cheetah generates python modules out of its templates
> hence the "dotted notation". and that has nothing to do with
> turbocheetah. as far as i know, the only task of turbocheetah is to
> regenerate python code once source template is updated.
Actually, TurboCheetah does it all. It does it differently than you
would in a typical Python program.
if "cheetah.precompiled" config var:
import .py template module and return it
else:
if compiled template in memory cache:
return it
else:
compile template to memory
put in cache
return it
TurboCheetah uses pkg_resources to load the file so that it works with
zipped eggs. I don't think that strictly requires the directory to be
a module.
Mako in contrast loads the template directly by pathname (in
lookup.py), and uses a caching library to store the compiled template.
This makes more sense although I presume it's not compatible with
zipped eggs. If the filename doesn't have a slash it first attempts
to convert it from dotted notation to URI notation.
I'm thinking Buffet (pylons.templating) needs more formalization on
what the plugins should do, what notation, what the standard options
and their meanings are, etc.
> > 1) Do you have a Pylons or TurboGears site that's using TurboCheetah?
>
> yes. we have one application powered by pylons/cheetah
>
> > 2) Would it be a hardship to convert your render_response or @expose
> > to URI notation?
>
> although replacing slashes with dots would be piece of cake what would
> be the gain? you'd still have to use "dotted notation" inside cheetah
> templates when you want to refer another template.
The advantages of URI notation is you can use characters not allowed
in module names, you can name templates *.html, have two templates
A.html and A.xml for different output formats, and you wouldn't need
to have __init__.py in the template directories.
However, #extends needs a .py template module, so that's a major
argument in favor of dotted notation.
The problem is that we're getting two different notation systems for
different types of templates. TurboCheetah, following Kid's and
Genshi's lead, uses dotted notation and requires __init__.py, even
though the templates aren't Python modules. Meanwhile, Myghty and
Mako and presumably future engines use URI notation. Dotted notation
makes sense for precompiled template modules, which I think Kid stores
in the same directory but Cheetah stores in a dict in memory. Mako
stores compiled templates in a completely different directory
(data/templates), or at least in Pylons it does. The purpose of
Buffet was to unify the template front-ends so you could switch from
one to another easily. But with them having different notations this
is difficult.
render_request("myghty", "/index.myt")
render_request("kid", "index") # /index.kid
render_request("genshi", "index") # /index.html
render_request("cheetah", "index") # /index.tmpl
render_request("mako", "/index.html")
render_request("stan", ???)
Of course, there are tradeoffs both ways. It would be nice to just
change the engine argument and suddenly your template in the other
language works. But Mako and Genshi already have overlapping
extensions (*.html), and if every engine is using a site template of
some sort, all of those have to be uniquely named or kept in their own
directories. When I'm choosing between two template languages for the
same controller, I've gone to just having a separate render_request
line for each, and commenting the ones I'm not currently using. I
also put the engine argument in always, so the reader can immediately
tell which one is being used.
--
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
-~----------~----~----~----~------~----~------~--~---
