List of available Jinja2 global symbols

[Patrick Spencer]

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?

[Jirka Vejrazka]

Hi there, I'm not a Jinja2 user, but standard Django templates get these variables via context processors‎. Check out https://docs.djangoproject.com/en/1.8/topics/templates/#context-processors

 HTH

   Jirka

--
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...@googlegroups.com.
To post to this group, send email to django...@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/537bd366-180e-4876-8b91-5791f8e22d44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Patrick Spencer]

After reading a bit, it looks like only the Django Template backend can use context processors, not the Jinja2 backend. If this is true then Jinja2 isn't using any context processors  I'm wondering how the Jinja2 templates are getting the value for csrf_token and request then. I guess from the middleware. I just wish there was a list of globals that were accessible from the JInja2 templates.

[knbk]

I don't believe there's a list in the documentation, but you can get them from the source code at https://github.com/django/django/blob/master/django/template/backends/jinja2.py#L66:

if request is not None:
    context['request'] = request
    context['csrf_input'] = csrf_input_lazy(request)
    context['csrf_token'] = csrf_token_lazy(request)

[James Schneider]

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:

https://docs.djangoproject.com/en/1.8/ref/templates/api/#django-template-context-processors-csrf

https://docs.djangoproject.com/en/1.8/ref/templates/api/#django-template-context-processors-request

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

https://docs.djangoproject.com/en/1.8/ref/settings/#template-context-processors

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:

https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-TEMPLATES-OPTIONS

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

[Patrick Spencer]

This explains where the csrf_token and request symbols were loaded. Thanks for pointing that out.

[Patrick Spencer]

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?

[Carl Meyer]

On 11/22/2015 06:21 PM, Patrick Spencer wrote:
> 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.

Yes, the default additions to the Jinja2 template context should be
documented, and (as far as I can tell) are not. I've filed
https://code.djangoproject.com/ticket/25804 for this.

> 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.

That's right, the Jinja2 backend doesn't support context processors.
There's an accepted ticket for it
(https://code.djangoproject.com/ticket/24694) and I have an
implementation floating around, just need to polish it up, integrate it
with Django, and add tests and docs.

> 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.

Yes, I believe that the debug-toolbar's support for detecting rendered
templates is DTL-specific (it predates Django's Jinja2 support by quite
a few years). Really this is an enhancement request for
django-debug-toolbar, though it may require better debug hooks in the
Django template rendering system so DDT can hook in at the generic
template-rendering layer rather than the DTL-engine layer.

> 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?

The simplest solution for now may be to add context-processor support to
the Jinja2 backend, which can be done without too much difficulty by
subclassing it.

Carl