Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow the jinja2 environment class to be overridden. #1056

Closed
wants to merge 1 commit into from

Conversation

smurfix
Copy link

@smurfix smurfix commented May 12, 2014

I need this change because I have to override a couple of Jinja2's templating functions.

Better than monkeypatching flask.app.Environment. ;-)

@danielchatfield
Copy link

If I recall correctly, pretty much this exact thing got rejected and the response was that you should subclass Flask to change that. I'll see if I can find it.

@danielchatfield
Copy link

I can't find the exact issue in the couple of minutes I spent looking but the recommended way of doing this is to create a subclass of Flask and change the jinja_env method. May I ask why you are overriding jinja2s templating functions?

@smurfix
Copy link
Author

smurfix commented May 13, 2014

OK, I did it that way, no problem.

What I'm trying to do is to get jinja2 to accept and (ideally) debug my templates. I'm loading them from a database, and there's no reason why I couldn't store the compiled code alongside the source.

However I haven't made any inroads into providing meaningful backtraces yet, when the template's "filename" is really the database index.

@char101
Copy link

char101 commented Aug 21, 2014

How do I override create_jinja_environment without having to copy paste the implementation or monkey patching the environment object?

I think providing overridable flask environment class will result in much cleaner code than current alternatives.

@untitaker
Copy link
Contributor

Instead of introducing another attribute to the Flask object i'd suggest we add an optional environment_cls param to create_jinja_environment. Subclasses of Flask can then override the method with one that calls the parent method with this param.

@ThiefMaster
Copy link
Member

That sounds pretty ugly... and it will break if, for whatever reason, a future version adds another argument which is passed by flask when calling the method.

I'd prefer the class attribute.

@untitaker
Copy link
Contributor

I only considered it because there are IMO already far too many attributes on the Flask object, many of them just being shortcuts of something else.

@untitaker
Copy link
Contributor

Apparently this has been duplicated by #1422. I've merged that PR since it also had a testcase. I liked your naming style more though, so I've also renamed the class.

Thanks!

@untitaker untitaker closed this Jun 6, 2015
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants