librelist archives

« back to archive

Modifying jinja loader on per request basis

Modifying jinja loader on per request basis

From:
Mark Holland
Date:
2015-02-10 @ 22:40
Hello,

I'm trying to find a mechanism to modify the jinja loader on a per request
basis. We are integrating with sixpack for a/b tests and want to be able to
override certain templates, depending on a chosen alternative.

Currently we're using multiple FileSystemLoaders wrapped in a ChoiceLoader
to provide an additional template load path for shared widgets etc. I've
tried creating an additional ChoiceLoader for each alternative, with the
first loader being the FileSystemLoader for the override directory.
Modifying app.jinja_loader works however app.jinja_env then caches the
overridden template path and subsequent requests to the regular site are
broken.

I've thought about swapping out app.jinja_env (possibly with the .overlay()
method) to provide a per-alternative jinja environment however the
attribute is a @locked_cached_property. I guess I could subclass Flask to
provide the necessary functionality however I wonder if there's a better
way?

Many thanks,
Mark

Re: [flask] Modifying jinja loader on per request basis

From:
Dorian Hoxha
Date:
2015-02-13 @ 15:55
I have no experience with the jinja2 loader, but why not have 1
CustomLoader and implement the logic inside there (if it makes sense)?

On Tue, Feb 10, 2015 at 11:40 PM, Mark Holland <mark@tails.com> wrote:

> Hello,
>
> I'm trying to find a mechanism to modify the jinja loader on a per request
> basis. We are integrating with sixpack for a/b tests and want to be able to
> override certain templates, depending on a chosen alternative.
>
> Currently we're using multiple FileSystemLoaders wrapped in a ChoiceLoader
> to provide an additional template load path for shared widgets etc. I've
> tried creating an additional ChoiceLoader for each alternative, with the
> first loader being the FileSystemLoader for the override directory.
> Modifying app.jinja_loader works however app.jinja_env then caches the
> overridden template path and subsequent requests to the regular site are
> broken.
>
> I've thought about swapping out app.jinja_env (possibly with the
> .overlay() method) to provide a per-alternative jinja environment however
> the attribute is a @locked_cached_property. I guess I could subclass
> Flask to provide the necessary functionality however I wonder if there's a
> better way?
>
> Many thanks,
> Mark
>