I have long been in favor of streamlining the way template engines are
configured, but I couldn't find a syntax that's substantially better
than what we have now, or sufficiently better to justify a
compatibility break. If we can come to a consensus on the API, I'd be
willing to change it.
The template ordering is useless AFAIK except to set the default.
Theoretically it could try each engine in turn until one accepts the
template, but engines cannot reliably distinguish between foreign
templates and syntax errors, and there's no Buffet exception for "not
my template". I believe users with multiple engines should explicitly
choose an engine each time anyway.
Why do you find it "difficult" to change the default engine, and what
would be easier? In a one-engine scenario, you simply change the
obvious template_engine argument in the config.init_app() call. In a
multi-engine scenario you have to do the list dance, but what would be
better?
One issue I have is you can set engine options in the list but not in
the init_app call. Although with the greater promotion of the
config['buffet.template_options'] variable, this may no longer be an
issue. Though environment.py needs examples of what you can do with
it.
BTW, what are your thoughts on the pylons.c issue? Specifically that
ppl have to change ${c.foo} to ${foo} or vice-versa when switching
to/from @expose. I see a few alternatives:
1. Leave it as is. Bad for flexibility.
2. Merge the dict into pylons.c and not into the top-level
template namespace. This would require ${c.foo} everywhere, so would
be opposed by TurboGears fans.
3. Merge the dict into pylons.c *and* into the top-level
namespace. This may be the best compromise because ${c.foo} would be
compatible with both systems but ${foo} would still be available for
TG fans. It may surprise users that pylons.c has been cluttered and
same-name attributes overwritten. But the template is normally the
last use of 'c' before the request finishes processing.
I assume ${c} and the other Pylons globals will be in the template
namespace, if they aren't already.
How much does Pylons want to recommend @expose in the docs and
tutorials? It's arguably a better way to organize one's code. We've
kind of implemented it quietly without discussing the ramifications.
It definitely deserves more exposure than just a trivial side feature.
Users will want guidance on when/how/why to use it or not. For
instance, i could have put it in the Blog Tutorial but I didn't want
to get too radical, and i also didn't think it was in 0.9.6.
--Mike
On Dec 12, 2007 6:55 AM, Mark Ramm <[EMAIL PROTECTED]> wrote:
>
> OK, I actually thought I had rolled this back out. So, so that's my fault.
>
> But my larger problem is that the hoops you have to go through to
> change the template engine are both unnecessary, and cumbersome.
>
> I would like changing the default template engine to be 1 line of very
> obvious code. Is there some reason we care about the order of the
> list of template engines, other than to set the default? It seems
> like the group of available template engines, and the one you want to
> be default are to seprate ideas.
>
> So, I would be all for moving this to environment.py but I would like
> to see it easier to change default template engines.
>
> --Mark
>
>
> On Dec 11, 2007 10:32 PM, Mike Orr <[EMAIL PROTECTED]> wrote:
> >
> > My Python-dev app includes the following in development.ini:
> >
> > # If you'd like to change the default template engine used to render
> > text/html
> > # content in decorator style controllers, edit this line.
> > template_engine.default = genshi
> >
> > This can easily confuse the majority of users who don't use
> > decorator-style controllers and may not understand what they are.
> > It's doubly confusing that Genshi is the default for decorator
> > controllers while Mako is the default for ordinary controllers. Not
> > to mention that Genshi is not a Pylons dependency.
> >
> > Does it even make sense to set the template engine in the config file?
> > It's really a programming choice, not a deployment choice. Unless
> > the developer has provided a complete set of redundant templates for
> > the alternate engine (which nobody will do), the user cannot switch
> > the default engine without breaking the application. It's not like
> > swiching a SQLAlchemy backend. Changing the template engine requires
> > programming changes in the application. So it belongs more in
> > environment.py than the config file.
> >
> > --
> > Mike Orr <[EMAIL PROTECTED]>
> >
> > >
> >
>
>
>
> --
> Mark Ramm-Christensen
> email: mark at compoundthinking dot com
> blog: www.compoundthinking.com/blog
>
> >
>
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
