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:
>
>
> 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
>
--
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 [email protected].
To post to this group, send email to [email protected].
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.
