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
decor
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.
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 t
On Dec 12, 2007, at 1:42 PM, Mike Orr wrote:
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
On Dec 12, 2007 2:38 PM, Mark Ramm <[EMAIL PROTECTED]> wrote:
>
> > It should prolly be noted that the ini file is for deployment specific
> > settings. Nothing so critical to the apps internal structuring should
> > be in the ini like the template engine to use.
>
> Sure, that's fine and make
> It should prolly be noted that the ini file is for deployment specific
> settings. Nothing so critical to the apps internal structuring should
> be in the ini like the template engine to use.
Sure, that's fine and makes good sense. I will mention though that's
not what was done in tg, so i
Mark Ramm wrote:
>> It should prolly be noted that the ini file is for deployment specific
>> settings. Nothing so critical to the apps internal structuring should
>> be in the ini like the template engine to use.
>
> Sure, that's fine and makes good sense. I will mention though that's
> not
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
On Dec 12, 2007 4:47 PM, Mark Ramm <[EMAIL PROTECTED]> wrote:
>
> 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
One other thing I want is a way to specify an exact renderer object
rather than depending on entry point lookup. So something will have
to have a renderer argument somewhere. i'm just afraid that in the
switchover to Buffet2 renderers and multiple renderers for the same
engine, people might type
TG2 follows the Pylons config format 100% right now. Which is fine
with me now that i grok some of the thinking behind it. but I have to
agree that the template stuff is convoluted and confusing. At least
I'm confused, and therefore apparently TG2 doesn't do things right,
and I still don't qui
11 matches
Mail list logo
