kwargs for render()

[alex bodnaru]

hello friends,

the tg/render.py render function is well designed to receive and pass the kwargs
argument, to the renderer.
but unfortunately, the kwargs parameter is being lost in the calling process in
tg/controllers/decoratedcontroller.py.

i specifically miss this option, since i wish to use a genshi template for xml
output (without auto-generated DOCTYPE). a doctype kwarg would solve my problem,
though i had to patch RenderGenshi to extract doctype from template_vars, which
is being passed from the controller.

could you any solution?

thanks in advance,
alex

[Alessandro Molina]

setting response.content_type to text/xml should make the Genshi
renderer use the proper doctype.
Using @expose('temaplate', content_type='text/xml') should also work.

> --
> You received this message because you are subscribed to the Google Groups "TurboGears" group.
> To post to this group, send email to turbo...@googlegroups.com.
> To unsubscribe from this group, send email to turbogears+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
>

[Christoph Zwerschke]

Am 07.02.2012 11:51, schrieb alex bodnaru:
> the tg/render.py render function is well designed to receive and pass the kwargs
> argument, to the renderer.
> but unfortunately, the kwargs parameter is being lost in the calling process in
> tg/controllers/decoratedcontroller.py.
>
> i specifically miss this option, since i wish to use a genshi template for xml
> output (without auto-generated DOCTYPE). a doctype kwarg would solve my problem,
> though i had to patch RenderGenshi to extract doctype from template_vars, which
> is being passed from the controller.

We already made some improvements in that regard, e.g. here:
http://sourceforge.net/p/turbogears2/tg2/ci/1f4d3ae0866de3e9bd6c1f858156d7cde7c8d588/tree/tg/render.py?diff=fcb3cb5484d3bc02bf8a99eda2c8361c5be332d8

-- Christoph

[alex bodnaru]

thanks alessandro,

i tried the second to no avail: doctype row was added.

as for the first, genshi didn't seem to work.

here's my template:
<?xml version="1.0" encoding="utf-8"?>
<x.
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:py="http://genshi.edgewall.org/"
py:strip="True">
<xi:include href="func_compare.html" />
<div py:replace="compare_data(items, params)" />
</x>
my changes to render that worked turned to be randomal (as a result of editing
error), so i can't count on them too.

but i found a solution that did work for me:
return tg.render.render(self.data(customer, items_to_compare),.'genshi',
'example.templates.compare-core')

however, i left the mainstream code in order to try any of your advices

thanks, alex

[alex bodnaru]

hello chris,

thanks for your answer.
i unfortunately couldn't apply the patch. probably a newer tg is needed.

should i try trunk?

my solution so far is :

tg.render.render(self.data(customer, items_to_compare),. 'genshi',
'example.templates.compare-core')

thanks a lot,
alex

[Christoph Zwerschke]

Am 07.02.2012 20:31, schrieb alex bodnaru:
> i unfortunately couldn't apply the patch. probably a newer tg is needed.

You, don't need to patch. The patch has already been improved further
and is included in TG 2.1.4.

-- Christoph

[alex bodnaru]

so that's what i have right now :).

thanks, alex

[Alessandro Molina]

I checked on code and you are right, the text/xml doc is missing.
You should be able to solve your issue by monkeypatching the
RenderGenshi.doctypes_for_content_type adding the knowledge about
text/xml.

The change is quite simple, anywhere inside your code add:

from tg.render import RenderGenshi
RenderGenshi.doctypes_for_content_type.update({'text/xml' : (None, )})

Then the @expose('template', content_type='text/xml') should work correctly.

[alex bodnaru]

thanks a lot alessandro.

it's quite elegant, however monkeypatch ;) .

will it be patched officially?

best regards,
alex

[Christoph Zwerschke]

Am 08.02.2012 10:21, schrieb Alessandro Molina:
> I checked on code and you are right, the text/xml doc is missing.
> You should be able to solve your issue by monkeypatching the
> RenderGenshi.doctypes_for_content_type adding the knowledge about
> text/xml.

Hm, it seems not even that will help. The real problem is that the
templating.genshi.doctype and templating.genshi.method settings and
their default value "xhtml" take precedence over auto-determining the
doctype via response.content_type, so that our nice auto-determination
mechanism never really gets executed.

Your last patch solves the op's problem, but now it levers out both the
config settings and the auto-determination which is even worse.

This also reveals that we have not enough unit tests for this issue.

I'll work on these problems today.

-- Christoph

[Alessandro Molina]

On Wed, Feb 8, 2012 at 11:55 AM, Christoph Zwerschke <ci...@online.de> wrote:

> Your last patch solves the op's problem, but now it levers out both the
> config settings and the auto-determination which is even worse.
>

Do you mean the last commit on development branch?

It is not strictly related to this issue, the target was to provide a
way to enforce the doctype removal when manually calling the
tg.render.render method.
This is because tg.render.render might often be used to render
partials and you would end having the doctype in each partial.
Setting the DOCTYPE to None meant "use automatic detection" and there
was no way to tell to genshi not to put it.

Now it should be possible to use all the three options:
- Do not pass doctype to tg.render.render mean automatic detection
- Set it to None to enforce no doctype
- Set it to any string to force it if available for that content_type

It still doesn't solve in any way the issue of alex as there is still
no way to enforce a doctype from the expose decorator or from the
controller method. Adding text/xml to doctypes_for_content_type with
None provides a fix for XML target output, but we should think if we
want a more general way or if it is enough as genshi is actually able
to render only a known set of documents when used in xml mode.

[Christoph Zwerschke]

Am 08.02.2012 12:10, schrieb Alessandro Molina:
> Now it should be possible to use all the three options:
> - Do not pass doctype to tg.render.render mean automatic detection
> - Set it to None to enforce no doctype
> - Set it to any string to force it if available for that content_type

Ok, I'll add tests for all these use cases.

We still have to clarify what takes precedence,
templating.genshi.doctype (which was set excplicitly, but as a static
value) or the doctype derived from response.content_type via
doctypes_for_content_type.

Also, maybe we should allow templating.genshi.doctype to be a dict in
which case doctypes_for_content_type would be updated by that dict. Same
for templating.genshi.method and methods_for_content_type.

We could then let templating.genshi.doctype take precedence (as we
currently do), but we shouldn't set in the quickstart templates any more
so that the default automatic detection is active.

Does that make sense?

> It still doesn't solve in any way the issue of alex as there is still
> no way to enforce a doctype from the expose decorator or from the
> controller method. Adding text/xml to doctypes_for_content_type with
> None provides a fix for XML target output, but we should think if we
> want a more general way or if it is enough as genshi is actually able
> to render only a known set of documents when used in xml mode.

I would not add None values to doctypes_for_content_type but assume the
doctype value is None for all content types not contained in the dict.

If you want to render a special doctype I think you can always include
that verbatim in the template and set doctype=None when rendering.

-- Christoph

[alex bodnaru]

this is being done already by dict.get(key). but when using the xml rendering
method, genshi would tolerate no doctype in it's args.

>
> If you want to render a special doctype I think you can always include that
> verbatim in the template and set doctype=None when rendering.

however it would be great to guess the parameters of each supported engine,
freedom should be left to allow controller methods to get their exact rendering
parameters' that might well be the mere reason of an user to choose one engine
over the others.
>
> -- Christoph
>
--
alex

[Alessandro Molina]

On Wed, Feb 8, 2012 at 1:30 PM, Christoph Zwerschke <ci...@online.de> wrote:
> Am 08.02.2012 12:10, schrieb Alessandro Molina:
>
>> Now it should be possible to use all the three options:
>>   - Do not pass doctype to tg.render.render mean automatic detection
>>   - Set it to None to enforce no doctype
>>   - Set it to any string to force it if available for that content_type
>
> Ok, I'll add tests for all these use cases.
>

Should already be covered by the "test_genshi_autodoctype_*" and
"test_genshi_doctype_removal" suite of tests, so you should be fairly
safe modifying that parts.

> We still have to clarify what takes precedence, templating.genshi.doctype
> (which was set excplicitly, but as a static value) or the doctype derived
> from response.content_type via doctypes_for_content_type.
>

response.content_type should have precedence but favoring the
templating.genshi.doctype option when available.
The current behavior seems quite good.
Making templating.genshi.doctype have precedence would make impossible
to be able to serve anything else apart from whatever you choose in
templating.genshi.doctype and that would prevent being able to use
genshi to generate xml documents or as a text templating system for
anything else.

> Also, maybe we should allow templating.genshi.doctype to be a dict in which
> case doctypes_for_content_type would be updated by that dict. Same for
> templating.genshi.method and methods_for_content_type.
>

That seems to be a good idea, it would allow to disable doctype or add
specific doctype options for custom cases.

> We could then let templating.genshi.doctype take precedence (as we currently
> do), but we shouldn't set in the quickstart templates any more so that the
> default automatic detection is active.
>

I would say that we currently let response.content_type have
precedence, as the doctype that you specified gets used only if it is
said to be valid for the response.content_type. Otherwise the first
valid doctype for that content_type is used. So response.content_type
can override templating.genshi.doctype, but not the opposite, which
should be a good behavior.

[Christoph Zwerschke]

Am 08.02.2012 19:42, schrieb Alessandro Molina:
> response.content_type should have precedence but favoring the
> templating.genshi.doctype option when available.
> The current behavior seems quite good.

Sorry, today is very busy so I could not follow up. You're right, it's
already quite clever. I'll see tomorrow if there are still
features/tests that should be changed/added.

-- Christoph

[alex bodnaru]

thank you both for the great work and interest you have devoted for the case i
found :)

alex

[Christoph Zwerschke]

As Alessandro said, the rendering options wre already quite
sophisticated and well-tested.

Anyway, as suggested by Alex, I have added two more features that allow
the last fine-tuning of the rendering options.

1) You can now add rendering parameters to the expose decorator.
E.g. for suppressing the doctype, you can do this:

@expose('genshi_template', render_params=dict(doctype=None))

2) You can now override the default mappings of content types
to doctypes and methods for the Genshi renderer, by setting
templating.genshi.doctype and templating.genshi.method in
the config to such mappings instead of fixed strings.

Checked in as commit:2cf110e452. Let me know what you think.

-- Christoph

[alex bodnaru]

great idea cristoph.

thanks a lot.

i'll apply the patch asap.

alex

[alex bodnaru]

hello christoph,

i'm ashamed to tell that i didn't find your code.
is it not in git?

please clarify this matter,
alex

On 02/09/2012 06:02 PM, Christoph Zwerschke wrote:

[Christoph Zwerschke]

Am 13.02.2012 11:56, schrieb alex bodnaru:
> i'm ashamed to tell that i didn't find your code.
> is it not in git?

It is, at git.code.sf.net/p/turbogears2/tg2, but you have to look in the
development branch.

-- Christoph

[alex bodnaru]

do laugh at me, but i'm new to git and friends.
how could i pull it?

alex

[Christoph Zwerschke]

Am 13.02.2012 12:24, schrieb alex bodnaru:
> do laugh at me, but i'm new to git and friends.
> how could i pull it?

git checkout development

[alex bodnaru]

thanks a lot christoph,

it works great.
i appologize again for my ignorance in git.

best regards,
alex