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! 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! > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
