Sunday, November 22, 2015

Re: List of available Jinja2 global symbols

I see what you mean about not being about to have a global list of symbols because everything is subject to change. But it would be nice to have a default list of symbols available depending on the default initial setup.

I think the csrf_token and request token are available in the django.templates.backend.jinja2 module, as knbk pointed out.

I still don't think the jinja template processor is able to load context_processors. Right now my messages aren't working and I think this is the reason.

Also, I have django debug bar but when I load a jinja2 template with it it says that no templates have been loaded and I can't see any context processors. I think this is a bug. 

Does anyone have an idea about how to tell if django is actually loading the context_processors when it loads a jinja template. Also, does anyone have an idea how to make messages work with jinja templates?

On Sunday, November 22, 2015 at 5:47:58 PM UTC-6, James Schneider wrote:
I'm using Django 1.8.6 with the built in JInja2 support. I spent a while trying to figure out how to pass a csrf token to a JInja2 template. After a while I realized one could just write {{ csrf_token }} in the template, without passing this value through a view, and it would just print out the token. I also realized you could reference a request object without passing it through the view i.e. {{ request.user }} returns the current user. Is there a place in the documentation with all the available global symbols one can use in a Jinja2 template?

There are no 'global symbols' in Django. The closest you'll come is the list of project settings made available from django.conf.settings (https://docs.djangoproject.com/en/1.8/topics/settings/#using-settings-in-python-code). The reason that such a list doesn't exist is because it would be impossible to create a static one in the documentation. Everything that is available in the context of a template is generated and made available based on the specific project configuration, with additional information provided by the views.

There are a number of different sources used to populate/modify the template context:
  • Template Context Processors
  • Template Tags
  • Views
The {{ csrf_token }} variable and the {{ request }} variable are made available by two specific template context processors, respectively:


You can see the default context processors that are enabled here:


It would appear that you've modified that list at some point, as the 'request' context process is not included by default. It is also possible that you added the extra processors to the OPTIONS for Jinja2 integraiton:


This is, of course, assuming that you are using RequestContext in your function-based views, or the generic class-based views (which use RequestContext by default). 

To see what is available in your context (which is likely different per page view), I would recommend installing the django-debug-toolbar, which in addition to a ton of other valuable tools, allows you to inspect everything that is available in the template context for each page load.

I think the answer to your question is that Django is still rendering your template, just using Jinja2 rather than the internal template engine. While I've never used Jinja2, I'm guessing that Django is still smart enough to understand it's native variable/context references whilst rendering using a different engine. You may also want to investigation the OPTIONS setup I referenced earlier, as it sounds like that may make the same information available natively to the Jinja2 tags and however Jinja2 normally references variables.

-James

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/d3c3cb49-3914-42dd-bdc3-732561be87e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment