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
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
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.
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
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