We Keep Coding

Access a variable in HTML from a .py file [duplicate]

base.html is used as the base template for all other pages. base.html has the navigation bar and in the navigation bar, I want to show the number of messages the user received. Thus, I need to have a variable like {{number_of_messages}} in the base.html.
However, how should I pass this variable to it? Every template extends base.html and is rendered by a function. I don't think returning number_of_messages in all functions is a good way. Is there better way to implement this? How can I pass this variable to all templates?

You can use tags.
#myproject/myproject/templatetags/tags.py
from django import template
register = template.Library()
#register.simple_tag
def number_of_messages(request):
return _number
In your Base.html
{% load tags %}
{% number_of_messages request %}

Have a look at:
https://docs.djangoproject.com/en/dev/ref/templates/api/#django.template.RequestContext
As long as:
you use the render shortcut in your view (or otherwise take care to use a RequestContext to render your response)
have django.contrib.auth.context_processors.auth in your TEMPLATE_CONTEXT_PROCESSORS setting (as it is by default)
...then you have the current request's User (or AnonymousUser) instance available in your template as {{ user }} ...I am guessing from there you may be able to access the number of messages directly?
Or perhaps you are using Django's messages framework?
This comes with it's own context processor which (as long as you use render or RequestContext) will make a {{ messages }} var (containing the messages for current user) available in your templates. For 'number of messages' you can do {{ messages|length }}
If none of these built-in options provide what you need you can either:
make your own template context processor which will run for every request and make additional variables available to all templates (when rendered with a RequestContext)
make your own template tag which can be used only where needed... of course if this is used in your base.html and all templates inherit from base.html then it's still going to run for every page.

I find the simplest steps to passing variables to your base templates in django is to add a context_processor.py file like so:
In your app create context_processors.py and declare your variables e.g.:
# context_processors.py
def message_processor(request):
if request.user.is_authenticated:
no_msgs = request.user.profile.msgs
else:
no_msgs = 0
return {
'messages' : no_msgs
}
Then register your process or under TEMPLATES in your settings.py file:
TEMPLATES = [
{
...
'context_processors': [
...
# custom
'appname.context_processors.message_processor',
],
},
},
]
And then you will be able to get that variable anywhere in your app as:
{{ messages }}

If you want the variable in really all the views, then a custom template context processor is probably the best option.
https://docs.djangoproject.com/en/dev/ref/templates/api/#subclassing-context-requestcontext
If you want the variable only in some of the views, then you can make those views call a common function that populates the common variables, something like this:
def some_view(request):
params = _common_params(request)
params.update({
# params specific to .some_view
})
return render_to_response('path/to/template, params)
or create a custom decorator like this:
from functools import wraps
def render_with_params():
def _inner(view_method):
def _decorator(request, *args, **kwargs):
params = _common_params(request)
(template_path, view_params) = view_method(request, *args, **kwargs)
params.update(view_params)
return render_to_response(template_path, params, context_instance=RequestContext(request))
return wraps(view_method)(_decorator)
return _inner
#render_with_params()
def some_view(request):
params = { ... }
return ('path/to/template', params)

Context Processor for specific app only

'context_processors': [
...
...
"publicfront.views.context_processors.add_event_url"
],
I added this context processor in settings.py and want to use only for a specific app. How could I achieve this?

The context processor is run for all requests.
If you need to mimic the functionality you speak about, then you could add some if/else conditions in the context processor function, which gets the request object as first argument, so you may determine which app is running and populate the returned dict accordingly

Most of the answers I've found so far are about adding a context_processors into the site's settings.py. But I want my application to be an independent development unit. On deployment, I don't want to perform on the site unnecessary adjustments that I could've included into the distribution. As it was already hinted above (by Daniel Roseman), we can use custom tags (doc):
# file `extras.py`
from django.template.defaultfilters import register
import platform
CURRENT_OS = platform.system()
#register.simple_tag
def current_os():
return CURRENT_OS
That can be used like this:
{% load extras %}
. . .
<div>{% current_os %}</div>
As the request object is accessible in a template it may be processed with a custom filter (doc) like this:
# file `extras.py`
#register.filter
def my_filter(req):
return req.GET.get('q')
Usage:
<div>You searched for '{{ request|my_filter }}'.</div>

How do I pass variables to all templates in django? [duplicate]

This question already has an answer here:
Django - How to make a variable available to all templates?
(1 answer)
Closed 6 years ago.
I am trying to pass variables (browser variable) to all my templates in my app. Any advice on how to get it to work?
View:
def browser(request):
primary_cat_list = Categories.objects.order_by("category")
subcat_list = SubCategories.objects.order_by("sub_category")
product = Productbackup.objects.order_by("website")
browser = list(chain(primary_cat_list, subcat_list, product))
return render_to_response('reserve/templates/base.html', locals(), context_instance=RequestContext(request))
Template:
{% for prod in browser %} {{ prod }}, {% endfor %}

You, my friend, are in the market for Context Processors.
From a blog entry written by a far nimbler and erudite technical writer than I:
What are template context processors?
Django’s context processors are a facility that allows you to provide data and callbacks to your templates.
You can do so in one of two ways:
On an individual request basis: by passing a custom Context value to your render_to_response() call
Globally: by creating a context processor method that accepts a HttpRequest object as input, and returns a payload or callback, then
registering the context processor in your settings.py, then providing your render_to_response() call with the built-in RequestContext attribute
instead of your own (you can always extend RequestContext to add more data on an individual request basis of course).
If that approach for passing data to templates sounded absurd and obfuscated to you, you’re not alone. The complexity involved in such a simple operation is unwarranted and counter-productive, but every system has its shortcomings.
The official documentation is here:
https://docs.djangoproject.com/en/dev/ref/templates/api/
So but yeah, I have been programming with Django for a while, and one of the reasons I really like solving problems w/ it is because it is almost Byzantine in its complexity, but not in a domineering sort of way. It has a ton of geegaws and doodads that may not immediately appear useful; each of these either comes in extremely handy when you need it, and it will stay out of your way if not.
The upshot here for you is: context processors are a fine example of those. Yes.

Currently you're passing locals() as the variable scope which should include browser aswell, but I find the use of locals() very ugly.
Personally I always prefer a pattern like this instead:
def browser(request):
context = RequestContext(request)
primary_cat_list = Categories.objects.order_by("category")
subcat_list = SubCategories.objects.order_by("sub_category")
product = Productbackup.objects.order_by("website")
browser = list(chain(primary_cat_list, subcat_list, product))
context['browser'] = browser
return render_to_response('reserve/templates/base.html', context_instance=context)

I can give you an example of my code, that works fine. Here is the file named context_processors.py:
context_processors.py
def base(request):
user = request.user
#======================
#Login form
#=====================
# here is the code for login user or check if he is logged in already
return {
'user': user,
}
and that's, part of my base.html (a template that I use wor all my pages)
base.html
{% if user.username %}
<h3>
Welcome {{ user.username }}
</h3>

Persistent "CSRF token missing or incorrect.". Jinja and django-registration setup

I receive this message:
CSRF token missing or incorrect.
In most forums, the tell you to get the {% csrf_token %} in the form, and i do have it.
Also i have in my settings.py:
TEMPLATE_CONTEXT_PROCESSORS = (
"django.contrib.auth.context_processors.csrf",
"django.contrib.auth.context_processors.auth",
)
I am using jinja, which didn't seem to use CSRF, but then i installed django registration and i got lost, since, it seems to be using some other views, that i don't have access to so to say, they are not written by me, and i can't figure out where they are. "standard auth views" as they call them. So i am unable to add "RequestContext".
Any ideas what's going on and how I can get it going? thanx

You might have to rewrite the django-registration view manually. Looks like there's an issue with how Jinja likes to do things and how Django wants to configure template loaders..
To look at the standard auth views, just look under "site-packages" in your python installation.
You could try wrapping the standard auth views like this:
from django.contrib.auth.views import login, logout
from django.views.decorators.csrf import csrf_protect
#csrf_protect
def my_wrapped_login_view(request):
return login(request)
#csrf_protect
def my_wrapped_logout_view(request):
return logout(request)
I basically imported Django's standard auth views and called them with my own, which have the csrf_protect decoration. It's worth a shot.

Have you also got the standard Django Templating system installed? That will be required for most apps that are distributed with templates.
For CSRF, a context processor inserts the variable 'csrf_token' into the response context that it retrieves from the middleware if enabled. Now all you have to do, is make sure that it's apart of your form.
This is straight out of django.core, and is subject to change at any time.
if csrf_token:
if csrf_token == 'NOTPROVIDED':
return mark_safe(u"")
else:
return mark_safe(u"<div style='display:none'><input type='hidden' name='csrfmiddlewaretoken' value='%s' /></div>" % csrf_token)
However, seeing that, all you really need to know is that you have to have an input type named csrfmiddlewaretoken with the value of context.get('csrf_token','') within your form and that's all she wrote.

This answer isn't specific to django-registration, but just using Django with Jinja2 in general.
Django's CsrfViewMiddleware sets the csrf_token cookie if it determines that you have accessed the csrf_token context member. Unfortunately, Jinja2 rendering doesn't occur until after Django's middleware executes. As a result, the cookie doesn't get set, and therefore does not match the form, and you will get the 403 error.
To get around this issue, you need to access context['csrf_token'] at some point before you finish processing the response.
If you're using class-based views, you can create a CsrfProtectMixin:
class CsrfProtectMixin(object):
def render_to_response(self, context, **response_kwargs):
# Csrf processing happens when using a RequestContext.
# Be sure to use one.
if not isinstance(context, RequestContext):
context = RequestContext(self.request, context)
# Force access to csrf_token due to the way jinja2 renders the template
# after middleware has finished processing. Otherwise, the csrf cookie
# will not be set.
str(context.get('csrf_token'))
return super(CsrfProtectMixin, self).render_to_response(context, **response_kwargs)
And then in your view class:
class MyView(CsrfProtectMixin, TemplateView):
def get(self, request, *args, **kwargs):
context = {}
return self.render_to_response(context)
If you're not using class-based views, you can do something like:
def my_view(request):
context = RequestContext(request)
str(context['csrf_token']) #force access to the csrf_token
return render_to_response('template.html', context)
Or perhaps monkey patch render_to_reponse with the logic in the class, above.

The most straightforward answer to this one is to just put {% csrf_token %} within the form tag in your template/html.

I just switched off the csrf middleware in the settings like so, and now it works:
#'django.middleware.csrf.CsrfViewMiddleware',

Django: Template context processor request variable

I am trying to implement django-facebookconnect, for I need to check if a user logged in via Facebook or a regular user.
At the template, I can check if user logged in via facebook by checking request.facebook.uid
such as:
{% if is_facebook %}
{% show_facebook_photo user %}
{% endif %}
For this, I need to pass is_facebook': request.facebook.uid to the template and I will be using this in everywhere thus I want tried to apply it to an existing template context processor and call the snipplet above at the base.html, and it works fine for Foo objects:
def global_variables(request):
from django.conf import settings
from myproject.myapp.models import Foo
return {'is_facebook': request.facebook.uid,'foo_list': Foo.objects.all()}
I can list Foo objects at any view without any issue however it fails for this new is_facebook, it simply returns nothing.
If I pass 'is_facebook': request.facebook.uid in every single view , it works but I need this globally for any view rendering.

If you have access via the request object, why do you need to add a special is_facebook boolean at all? Just enable the built-in django.core.context_processors.request and this will ensure that request is present in all templates, then you can do this:
{% if request.facebook.uid %}

It could be a timing issue. Make sure that the Common middleware comes before the facebook middleware in your settings file. You can probably debug and see when the facebook middleware is modifying the request and when your context processor is invoked. That may give you some clue as to why this is happening. But, as Daniel said, you can always just use the request object in your templates.