TG2 specifying output encoding, content-type, etc, for genshi

9 views
Skip to first unread message

Nick Murdoch

unread,
Feb 9, 2009, 11:47:57 AM2/9/09
to TurboGears
Hi all,

I've been playing around with TG2 on a prototype project with the view
of using it for a real project if it supports everything I need.

Currently I'm having trouble finding how I can

* change Genshi's output between HTML and XHTML.
* change the Genshi default output encoding
* Make sure that the HTTP headers returned in the response match the
two items above.
* Make sure that incoming query string parameters are decoded to
unicode strings using the same encoding.
* Be able to access the encoding used in my functions

So far I've spent about two hours reading through docs and source and
haven't been able to find any of this out.

In tg1 with kid it was simply a case of setting the following in the
config file:

kid.outputformat="html"
kid.encoding="ISO-8859-1"

and then using the following in the code:

turbogears.util.get_template_encoding_default()

Any help with this would be great, since if I can't do this I'll have
to stick to using TG1, which would be a shame as there's a few nice
things in TG2 that I'd like to be able to use!

Thanks,

Nick

Cito

unread,
Feb 25, 2009, 4:17:10 AM2/25/09
to TurboGears
On 9 Feb., 17:47, Nick Murdoch <nickmurd...@gmail.com> wrote:
> I've been playing around with TG2 on a prototype project with the view
> of using it for a real project if it supports everything I need.
>
> Currently I'm having trouble finding how I can
>
> * change Genshi's output between HTML and XHTML.
> * change the Genshi default output encoding
> * Make sure that the HTTP headers returned in the response match the
> two items above.
> * Make sure that incoming query string parameters are decoded to
> unicode strings using the same encoding.
> * Be able to access the encoding used in my functions
>
> So far I've spent about two hours reading through docs and source and
> haven't been able to find any of this out.

Same for me. Can anybody shed some light on this?

-- Christoph

Jorge Vargas

unread,
Feb 25, 2009, 5:59:57 PM2/25/09
to turbo...@googlegroups.com
ok I'll bite.

first remember the original feature was a buffet thing which as you
all know it's deprecated. (I'll use the tag to keep links sane for the
future)

That said
option 1
turn buffet on.
set use_legacy_renderer in app_cfg.py

that will allow your code to call setup_default_renderer
http://trac.turbogears.org/browser/tags/2.0b5/tg/configuration.py#L375

and you can set the values you wan to send to genshi in
config['buffet.template_options'].update(options)
http://trac.turbogears.org/browser/tags/2.0b5/tg/configuration.py#L397

option 2

Umm I'm not sure if it's possible without patching some code. Or
adding it locally.

You will have to add your own renderer that will wrap the original one.
as the **kargs passed there will be send to genshi
http://trac.turbogears.org/browser/tags/2.0b5/tg/render.py#L111

and write something similar to
http://trac.turbogears.org/browser/tags/2.0b5/tg/configuration.py#L333
that will load your renderer.

> -- Christoph
> >
>

Mark Ramm

unread,
Feb 25, 2009, 7:20:58 PM2/25/09
to turbo...@googlegroups.com
There is currently only one supported way of doing this, but we should
add another.

Right now it is easy to write a render method that configures and uses
genshi however you want. And your custom render method can be stuck
in the renderers dictionary and even set as the default renderer.

This allows total flexibility in how genshi, mako, jinja2, and
whatever other template engine you want to use are setup -- and does
not limit you to a common subset of features supported by buffet.

But it would probably be a good idea to have a few simple options for
the three default renderers so you don't even have to write the couple
of lines of code required to create your own renderer for those common
cases.

--Mark
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog

Christoph Zwerschke

unread,
Feb 26, 2009, 7:04:23 AM2/26/09
to turbo...@googlegroups.com
Jorge Vargas schrieb:

> first remember the original feature was a buffet thing which as you
> all know it's deprecated. (I'll use the tag to keep links sane for the
> future)
>
> That said
> option 1
> turn buffet on.
> set use_legacy_renderer in app_cfg.py
>
> that will allow your code to call setup_default_renderer
> http://trac.turbogears.org/browser/tags/2.0b5/tg/configuration.py#L375
>
> and you can set the values you wan to send to genshi in
> config['buffet.template_options'].update(options)
> http://trac.turbogears.org/browser/tags/2.0b5/tg/configuration.py#L397

Ok, but this is not documented, it's more complicated than in TG1, and
most of all it's deprecated, so I really don't like to use it.

> Umm I'm not sure if it's possible without patching some code. Or
> adding it locally.
>
> You will have to add your own renderer that will wrap the original one.
> as the **kargs passed there will be send to genshi
> http://trac.turbogears.org/browser/tags/2.0b5/tg/render.py#L111
>
> and write something similar to
> http://trac.turbogears.org/browser/tags/2.0b5/tg/configuration.py#L333
> that will load your renderer.

I think that's a bit hefty when all I want is change one parameter of my
templating engine, e.g. setting the output method from xhtml to html.

Also, it's not documented. Surely something needs to be done about this.

Honestly speaking, I don't understand why things have been made so
complicated, why so much of the TG1 goodness has been given up so easily
and good ideas like Buffet have been deprecated. Flexibility is good,
but wasn't our motto for TG to keep simple things simple and complex
things possible? My impression is that the first part of the motto has
been forgotten in some areas of TG2 development.

-- Christoph

Christoph Zwerschke

unread,
Feb 26, 2009, 7:35:35 AM2/26/09
to turbo...@googlegroups.com
Mark Ramm schrieb:

> Right now it is easy to write a render method that configures and uses
> genshi however you want. And your custom render method can be stuck
> in the renderers dictionary and even set as the default renderer.

I think it's not so easy because it is not documented anywhere. And
there are some pitfalls. For instance, you cannot name your rendered
like one of the default renderers, even if you intend to replace one of
these, because this entry will be overwritten. You also cannot reuse the
default renderer function in your own function (unless you directly
import it) because in the config file they have not yet been set up.

> This allows total flexibility in how genshi, mako, jinja2, and
> whatever other template engine you want to use are setup -- and does
> not limit you to a common subset of features supported by buffet.

My feeling is that we have thrown away the baby with the bathwater here.
It was in fact possible to provide options specific to one
templating engine with buffet. If it had shortcomings, buffet should
have been improved instead of completely throwing it away. I guess the
problem was that nobody cared about buffet because nobody felt
responsible. Maybe we as TG community should have better enforced and
improved the buffet standard. But I guess it's probably too late already.

> But it would probably be a good idea to have a few simple options for
> the three default renderers so you don't even have to write the couple
> of lines of code required to create your own renderer for those common
> cases.

Either that or the couple of lines that you need to add should be
clearly documented with some examples. Best let's do both. (Just saw
that there is already a ticket http://trac.turbogears.org/ticket/2137
and added a comment. I think its priority should be set to high again.)

-- Christoph

Mark Ramm

unread,
Feb 26, 2009, 7:47:23 AM2/26/09
to turbo...@googlegroups.com
On Thu, Feb 26, 2009 at 7:35 AM, Christoph Zwerschke <ci...@online.de> wrote:
>
> Mark Ramm schrieb:
>> Right now it is easy to write a render method that configures and uses
>> genshi however you want.   And your custom render method can be stuck
>> in the renderers dictionary and even set as the default renderer.
>
> I think it's not so easy because it is not documented anywhere.

Agreed, and this is something we should fix. I started on this this
weekend, but did not finish.

But when the docs are completed they willl be here:

http://www.turbogears.org/2.0/docs/main/Templates/Alternative.html#writing-your-own-render-function

> And
> there are some pitfalls. For instance, you cannot name your rendered
> like one of the default renderers, even if you intend to replace one of
> these, because this entry will be overwritten. You also cannot reuse the
> default renderer function in your own function (unless you directly
> import it) because in the config file they have not yet been set up.

I don't think they won't be overwritten if you don't have them in the
list of renderers to prepare.

>> This allows total flexibility in how genshi, mako, jinja2, and
>> whatever other template engine you want to use are setup -- and does
>> not limit you to a common subset of features supported by buffet.
>
> My feeling is that we have thrown away the baby with the bathwater here.
>        It was in fact possible to provide options specific to one
> templating engine with buffet. If it had shortcomings, buffet should
> have been improved instead of completely throwing it away. I guess the
> problem was that nobody cared about buffet because nobody felt
> responsible. Maybe we as TG community should have better enforced and
> improved the buffet standard. But I guess it's probably too late already.


Yea, too late already. And there are many things that went wrong with
buffet and nobody was willing to do the work to fix it. And the
simple render function solution worked, and was what Pylons was using
so we standardized on it.

>> But it would probably be a good idea to have a few simple options for
>> the three default renderers so you don't even have to write the couple
>> of lines of code required to create your own renderer for those common
>> cases.
>
> Either that or the couple of lines that you need to add should be
> clearly documented with some examples. Best let's do both. (Just saw
> that there is already a ticket http://trac.turbogears.org/ticket/2137
> and added a comment. I think its priority should be set to high again.)

Yea, makes sense.

Christoph Zwerschke

unread,
Feb 26, 2009, 10:19:15 AM2/26/09
to turbo...@googlegroups.com
Mark Ramm schrieb:

Great. I can do some proof-reading then.

>> And there are some pitfalls. For instance, you cannot name your
>> rendered like one of the default renderers, even if you intend to
>> replace one of these, because this entry will be overwritten. You
>> also cannot reuse the default renderer function in your own
>> function (unless you directly import it) because in the config file
>> they have not yet been set up.
>
> I don't think they won't be overwritten if you don't have them in the
> list of renderers to prepare.

What I wanted to say is that you can't simply set

base_config.render_functions.genshi = my_render_genshi

since this will be overwritten with the default render_genshi function.
You need to do the following:

base_config.render_functions.my_genshi = my_render_genshi
base_config.renderers.append('my_genshi')
base_config.default_renderer = 'my_genshi'

I think the setup_* methods in AppConfig should not overwrite
render_functions that are already set.

-- Christoph

Mark Ramm

unread,
Feb 26, 2009, 2:04:02 PM2/26/09
to turbo...@googlegroups.com
> I think the setup_* methods in AppConfig should not overwrite
> render_functions that are already set.

That makes sense. Though I don't think they will setup an app if
it's not in the base_config.renderers list, right.

So if you set:

base_config.renderers = []
base_config.render_functions.genshi = my_renderer_for_genshi

it should work but that's weird, non-intuitive and ugly. I agree
with you that we should check the render functions before adding them.

--Mark Ramm

Reply all
Reply to author
Forward
0 new messages