Best way to specify renderer at runtime

[juha]

Hello,

I wanted to ask the community about this question I have concerning view renderers: say I wanted to add a level of indirection between the view callables and the associated renderer that I want to be determined at runtime (for example, I don't want to hardcode a specific template to a function with the view_config decorator, I want to select one of several versions of the template for WWW requests based on the logged in user's preference, debugging, etc.).

My use-case is creating a new layout for a website, and then having the templates in a path like v1/user/profile.jinja2 and v2/user/profile.jinja2, and having both available at the same time (a db table decides which user sees which) until the new layout is sufficiently tested to be rolled out to all users.

I understand this can be done with a NewRequest subscriber. Is this the canonical way if I know it's going to be used on every request?

Thanks for the help!

[Chris Rossi]

I'd write a new renderer, register it as the .jinja2 renderer, let it sort out the lookup logic.

Chris

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

[Jonathan Vanasco]

You can use a view_config with no renderer, then call `render_to_response`

This is my preferred method, because it gives me control within the views themselves.

If you're talking about changing an entire global template directory, and not just for some views, something like what Chris described would probably be easier.

===========

    from pyramid.renderers import render_to_response

    class Foo(baseClass):

          

         @view_config(route_name="profile"):

         def profile(self):

                version = derive_version()

                if version:

                    return render_to_response("profile-v%s.mako" % version, {}, self.request)

                 return render_to_response("profile.mako", {}, self.request)

             

[juha]

Jonathan - that's what I originally considered, but I think having views return just data is a good principle that I'd have a tough time giving up. The ability to have control on a per-view basis *is* rather lucrative (and I've just come up with a few ideas where I'd like to be able to do that), but on the other hand in my case all views will be affected. And the choice of renderer is a cross-cutting concern that I'd prefer to avoid in view logic.

Chris - I think you're right that a new renderer would be a somewhat cleaner approach in this case. I'll try it out.

Thank you both for your advice!

[John Anderson]

On Wed, May 20, 2015 at 4:39 PM, juha <kohezivnos...@gmail.com> wrote:

Jonathan - that's what I originally considered, but I think having views return just data is a good principle that I'd have a tough time giving up. The ability to have control on a per-view basis *is* rather lucrative (and I've just come up with a few ideas where I'd like to be able to do that), but on the other hand in my case all views will be affected. And the choice of renderer is a cross-cutting concern that I'd prefer to avoid in view logic.

Chris - I think you're right that a new renderer would be a somewhat cleaner approach in this case. I'll try it out.

Thank you both for your advice!

You can also just do:

request.override_renderer = 'jinja2'

If you need pyramid to use a different renderer

 

On Wednesday, May 20, 2015 at 10:24:00 PM UTC+2, juha wrote:

Hello,

I wanted to ask the community about this question I have concerning view renderers: say I wanted to add a level of indirection between the view callables and the associated renderer that I want to be determined at runtime (for example, I don't want to hardcode a specific template to a function with the view_config decorator, I want to select one of several versions of the template for WWW requests based on the logged in user's preference, debugging, etc.).

My use-case is creating a new layout for a website, and then having the templates in a path like v1/user/profile.jinja2 and v2/user/profile.jinja2, and having both available at the same time (a db table decides which user sees which) until the new layout is sufficiently tested to be rolled out to all users.

I understand this can be done with a NewRequest subscriber. Is this the canonical way if I know it's going to be used on every request?

Thanks for the help!

--

[wilk]

On 20-05-2015, juha wrote:
> ------=_Part_1143_229633732.1432165172186
> Content-Type: multipart/alternative;
> boundary="----=_Part_1144_426020065.1432165172186"
>
> ------=_Part_1144_426020065.1432165172186
> Content-Type: text/plain; charset=UTF-8

>
> Jonathan - that's what I originally considered, but I think having views
> return just data is a good principle that I'd have a tough time giving up.

Good point !

If you have the possibility you can use multiple view_config with
a custom view predicat.

--
William