What I want, and what seems to make the most sense to me is for there
to be a default engine which is used when no engine is chosen, and for
users to have to declare an engine the want to be the default. I
expect most users in a TG2 world filled with html, rss, json, xml,
amf3, and all kinds of other protocols to live in a multi-engine
setup. So I want to be able to make it easy to configure all your
engines, and easy to choose which one is the default
I the simple case, I don't want users to have to do the list dance to
declare a default engine And I want it to be done in a standard way
across TG2 and pylons so we don't have to document it as a difference
-- unless there is some compelling reason to make it different.
So, my proposal at the moment is to add a defaul_engine to be setup in
environment.py. The list can still be there, and can still function
the same way, it's just that rather than get the default from the
first item in the list, we'll get it from default_engine.
Is that a sensible solution, or am I missing something?
On Dec 12, 2007 4:42 PM, Mike Orr <[EMAIL PROTECTED]> wrote:
>
> 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]>
>
> >
>
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
