I have some stuff in settings.py that I'd like to be able to access from a template, but I can't figure out how to do it. I already tried
{{CONSTANT_NAME}}
but that doesn't seem to work. Is this possible?
If it's a value you'd like to have for every request & template, using a context processor is more appropriate.
Here's how:
Make a context_processors.py file in your app directory. Let's say I want to have the ADMIN_PREFIX_VALUE value in every context:
from django.conf import settings # import the settings file
def admin_media(request):
# return the value you want as a dictionnary. you may add multiple values in there.
return {'ADMIN_MEDIA_URL': settings.ADMIN_MEDIA_PREFIX}
add your context processor to your settings.py file:
TEMPLATES = [{
# whatever comes before
'OPTIONS': {
'context_processors': [
# whatever comes before
"your_app.context_processors.admin_media",
],
}
}]
Use RequestContext in your view to add your context processors in your template. The render shortcut does this automatically:
from django.shortcuts import render
def my_view(request):
return render(request, "index.html")
and finally, in your template:
...
path to admin media
...
I find the simplest approach being a single custom template tag:
from django import template
from django.conf import settings
register = template.Library()
# settings value
#register.simple_tag
def settings_value(name):
return getattr(settings, name, "")
Usage:
{% settings_value "LANGUAGE_CODE" %}
Django provides access to certain, frequently-used settings constants to the template such as settings.MEDIA_URL and some of the language settings if you use django's built in generic views or pass in a context instance keyword argument in the render_to_response shortcut function. Here's an example of each case:
from django.shortcuts import render_to_response
from django.template import RequestContext
from django.views.generic.simple import direct_to_template
def my_generic_view(request, template='my_template.html'):
return direct_to_template(request, template)
def more_custom_view(request, template='my_template.html'):
return render_to_response(template, {}, context_instance=RequestContext(request))
These views will both have several frequently used settings like settings.MEDIA_URL available to the template as {{ MEDIA_URL }}, etc.
If you're looking for access to other constants in the settings, then simply unpack the constants you want and add them to the context dictionary you're using in your view function, like so:
from django.conf import settings
from django.shortcuts import render_to_response
def my_view_function(request, template='my_template.html'):
context = {'favorite_color': settings.FAVORITE_COLOR}
return render_to_response(template, context)
Now you can access settings.FAVORITE_COLOR on your template as {{ favorite_color }}.
Check out django-settings-export (disclaimer: I'm the author of this project).
For example...
$ pip install django-settings-export
settings.py
TEMPLATES = [
{
'OPTIONS': {
'context_processors': [
'django_settings_export.settings_export',
],
},
},
]
MY_CHEESE = 'Camembert';
SETTINGS_EXPORT = [
'MY_CHEESE',
]
template.html
<script>var MY_CHEESE = '{{ settings.MY_CHEESE }}';</script>
Another way to do this is to create a custom template tag which can let you fish values out of the settings.
#register.tag
def value_from_settings(parser, token):
try:
# split_contents() knows not to split quoted strings.
tag_name, var = token.split_contents()
except ValueError:
raise template.TemplateSyntaxError, "%r tag requires a single argument" % token.contents.split()[0]
return ValueFromSettings(var)
class ValueFromSettings(template.Node):
def __init__(self, var):
self.arg = template.Variable(var)
def render(self, context):
return settings.__getattr__(str(self.arg))
You can then use:
{% value_from_settings "FQDN" %}
to print it on any page, without jumping through context-processor hoops.
I like Berislav's solution, because on simple sites, it is clean and effective. What I do NOT like is exposing all the settings constants willy-nilly. So what I ended up doing was this:
from django import template
from django.conf import settings
register = template.Library()
ALLOWABLE_VALUES = ("CONSTANT_NAME_1", "CONSTANT_NAME_2",)
# settings value
#register.simple_tag
def settings_value(name):
if name in ALLOWABLE_VALUES:
return getattr(settings, name, '')
return ''
Usage:
{% settings_value "CONSTANT_NAME_1" %}
This protects any constants that you have not named from use in the template, and if you wanted to get really fancy, you could set a tuple in the settings, and create more than one template tag for different pages, apps or areas, and simply combine a local tuple with the settings tuple as needed, then do the list comprehension to see if the value is acceptable.
I agree, on a complex site, this is a bit simplistic, but there are values that would be nice to have universally in templates, and this seems to work nicely.
Thanks to Berislav for the original idea!
Adding an answer with complete instructions for creating a custom template tag that solves this, with Django 2.0+
In your app-folder, create a folder called templatetags. In it, create __init__.py and custom_tags.py:
In the custom_tags.py create a custom tag function that provides access to an arbitrary key in the settings constant:
from django import template
from django.conf import settings
register = template.Library()
#register.simple_tag
def get_setting(name):
return getattr(settings, name, "")
To understand this code I recommend reading the section on simple tags in the Django docs.
Then, you need to make Django aware of this (and any additional) custom tag by loading this file in any template where you will use it. Just like you need to load the built in static tag:
{% load custom_tags %}
With it loaded it can be used just like any other tag, just supply the specific setting you need returned. So if you have a BUILD_VERSION variable in your settings:
{% get_setting "BUILD_VERSION" %}
This solution will not work with arrays, but if you need that you might be putting to much logic in your templates.
Note: A more clean and failsafe solution would probably be to make a custom context processor where you add the settings you need to a context available to all templates. This way you reduce the risk of outputting sensitive settings in your templates by mistake.
Add this code to a file called context_processors.py:
from django.conf import settings as django_settings
def settings(request):
return {
'settings': django_settings,
}
And then, in your settings file, include a path such as 'speedy.core.base.context_processors.settings' (with your app name and path) in the 'context_processors' settings in TEMPLATES.
(You can see for example settings/base.py and context_processors.py).
Then you can use the specific setting in any template code. For example:
{% if settings.SITE_ID == settings.SPEEDY_MATCH_SITE_ID %}
Update: The code above exposes all the settings to templates, including sensitive information such as your SECRET_KEY. A hacker might abuse this feature to display such information in the templates. If you want to expose only specific settings to the templates, use this code instead:
def settings(request):
settings_in_templates = {}
for attr in ["SITE_ID", ...]: # Write here the settings you want to expose to the templates.
if (hasattr(django_settings, attr)):
settings_in_templates[attr] = getattr(django_settings, attr)
return {
'settings': settings_in_templates,
}
I improved chrisdew's answer (to create your own tag) a little bit.
First, create the file yourapp/templatetags/value_from_settings.py in which you define your own new tag value_from_settings:
from django.template import TemplateSyntaxError, Variable, Node, Variable, Library
from yourapp import settings
register = Library()
# I found some tricks in URLNode and url from defaulttags.py:
# https://code.djangoproject.com/browser/django/trunk/django/template/defaulttags.py
#register.tag
def value_from_settings(parser, token):
bits = token.split_contents()
if len(bits) < 2:
raise TemplateSyntaxError("'%s' takes at least one " \
"argument (settings constant to retrieve)" % bits[0])
settingsvar = bits[1]
settingsvar = settingsvar[1:-1] if settingsvar[0] == '"' else settingsvar
asvar = None
bits = bits[2:]
if len(bits) >= 2 and bits[-2] == 'as':
asvar = bits[-1]
bits = bits[:-2]
if len(bits):
raise TemplateSyntaxError("'value_from_settings' didn't recognise " \
"the arguments '%s'" % ", ".join(bits))
return ValueFromSettings(settingsvar, asvar)
class ValueFromSettings(Node):
def __init__(self, settingsvar, asvar):
self.arg = Variable(settingsvar)
self.asvar = asvar
def render(self, context):
ret_val = getattr(settings,str(self.arg))
if self.asvar:
context[self.asvar] = ret_val
return ''
else:
return ret_val
You can use this tag in your Template via:
{% load value_from_settings %}
[...]
{% value_from_settings "FQDN" %}
or via
{% load value_from_settings %}
[...]
{% value_from_settings "FQDN" as my_fqdn %}
The advantage of the as ... notation is that this makes it easy to use in blocktrans blocks via a simple {{my_fqdn}}.
If using a class-based view:
#
# in settings.py
#
YOUR_CUSTOM_SETTING = 'some value'
#
# in views.py
#
from django.conf import settings #for getting settings vars
class YourView(DetailView): #assuming DetailView; whatever though
# ...
def get_context_data(self, **kwargs):
context = super(YourView, self).get_context_data(**kwargs)
context['YOUR_CUSTOM_SETTING'] = settings.YOUR_CUSTOM_SETTING
return context
#
# in your_template.html, reference the setting like any other context variable
#
{{ YOUR_CUSTOM_SETTING }}
The example above from bchhun is nice except that you need to explicitly build your context dictionary from settings.py. Below is an UNTESTED example of how you could auto-build the context dictionary from all upper-case attributes of settings.py (re: "^[A-Z0-9_]+$").
At the end of settings.py:
_context = {}
local_context = locals()
for (k,v) in local_context.items():
if re.search('^[A-Z0-9_]+$',k):
_context[k] = str(v)
def settings_context(context):
return _context
TEMPLATE_CONTEXT_PROCESSORS = (
...
'myproject.settings.settings_context',
...
)
If someone finds this question like I did, then I'll post my solution which works on Django 2.0:
This tag assigns some settings.py variable value to template's variable:
Usage: {% get_settings_value template_var "SETTINGS_VAR" %}
app/templatetags/my_custom_tags.py:
from django import template
from django.conf import settings
register = template.Library()
class AssignNode(template.Node):
def __init__(self, name, value):
self.name = name
self.value = value
def render(self, context):
context[self.name] = getattr(settings, self.value.resolve(context, True), "")
return ''
#register.tag('get_settings_value')
def do_assign(parser, token):
bits = token.split_contents()
if len(bits) != 3:
raise template.TemplateSyntaxError("'%s' tag takes two arguments" % bits[0])
value = parser.compile_filter(bits[2])
return AssignNode(bits[1], value)
Your template:
{% load my_custom_tags %}
# Set local template variable:
{% get_settings_value settings_debug "DEBUG" %}
# Output settings_debug variable:
{{ settings_debug }}
# Use variable in if statement:
{% if settings_debug %}
... do something ...
{% else %}
... do other stuff ...
{% endif %}
See Django's documentation how to create custom template tags here: https://docs.djangoproject.com/en/2.0/howto/custom-template-tags/
I found this to be the simplest approach for Django 1.3:
views.py
from local_settings import BASE_URL
def root(request):
return render_to_response('hero.html', {'BASE_URL': BASE_URL})
hero.html
var BASE_URL = '{{ JS_BASE_URL }}';
For those who want to use #Berislav's approach (custom template tag) with if tag:
/app/templatetags/my_settings.py:
from django import template
from django.conf import settings
register = template.Library()
#register.simple_tag
def settings_value(name):
return getattr(settings, name, "")
Template file:
<!-- Load your tags -->
{% load my_settings %}
{% settings_value 'ENABLE_FEATURE_A' as ENABLE_FEATURE_A %}
{% if ENABLE_FEATURE_A %}
<!-- Feature A stuffs -->
{% endif %}
Both IanSR and bchhun suggested overriding TEMPLATE_CONTEXT_PROCESSORS in the settings. Be aware that this setting has a default that can cause some screwy things if you override it without re-setting the defaults. The defaults have also changed in recent versions of Django.
https://docs.djangoproject.com/en/1.3/ref/settings/#template-context-processors
The default TEMPLATE_CONTEXT_PROCESSORS :
TEMPLATE_CONTEXT_PROCESSORS = ("django.contrib.auth.context_processors.auth",
"django.core.context_processors.debug",
"django.core.context_processors.i18n",
"django.core.context_processors.media",
"django.core.context_processors.static",
"django.contrib.messages.context_processors.messages")
If we were to compare context vs. template tags on a single variable, then knowing the more efficient option could be benificial. However, you might be better off to dip into the settings only from templates that need that variable. In that case it doesn't make sense to pass the variable into all templates. But if you are sending the variable into a common template such as the base.html template, Then it would not matter as the base.html template is rendered on every request, so you can use either methods.
If you decide to go with the template tags option, then use the following code as it allows you to pass a default value in, just in case the variable in-question was undefined.
Example: get_from_settings my_variable as my_context_value
Example: get_from_settings my_variable my_default as my_context_value
class SettingsAttrNode(Node):
def __init__(self, variable, default, as_value):
self.variable = getattr(settings, variable, default)
self.cxtname = as_value
def render(self, context):
context[self.cxtname] = self.variable
return ''
def get_from_setting(parser, token):
as_value = variable = default = ''
bits = token.contents.split()
if len(bits) == 4 and bits[2] == 'as':
variable = bits[1]
as_value = bits[3]
elif len(bits) == 5 and bits[3] == 'as':
variable = bits[1]
default = bits[2]
as_value = bits[4]
else:
raise TemplateSyntaxError, "usage: get_from_settings variable default as value " \
"OR: get_from_settings variable as value"
return SettingsAttrNode(variable=variable, default=default, as_value=as_value)
get_from_setting = register.tag(get_from_setting)
A more complete implementation.
/project/settings.py
APP_NAME = 'APP'
/app/templatetags/settings_value.py
from django import template
from django.conf import settings
register = template.Library()
#register.simple_tag
def settings_value(name):
return getattr(settings, name, "")
/app/templates/index.html
<!DOCTYPE html>
{% load static %}
{% load settings_value %}
<head>
<title>{% settings_value "APP_NAME" %}</title>
...
Related
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)
I would like to be able to render some or all of the views in my project with a different base template. In other words, for url /some/view I would like to be able to have /inline/some/view and have it render the same content, but using a different base template.
Modifying each view to accept a different template is not an option, because I would like to apply this behaviour across all apps in the project, including things like django.contrib.auth.
So far, I have, in urls.py:
url("^inline/(?P<uri>.*)", format.inline, name='inline'),
And the view, format.py:
from django.core.urlresolvers import resolve
def inline(request, uri=''):
# get the view that would normally handle this request
view, args, kwargs = resolve('/' + uri)
# call the view
kwargs['request'] = request
template_response = view(*args, **kwargs)
# ...now what?
I'm not sure where to go from here. Can I modify the entire template chain before I call view(), so that template_response.render() does the right thing?
Perhaps I am entirely off-base with this approach and should be looking at a middleware solution, but I am attached to the idea of this behaviour keying off URLs, because it will be easy to explain to the content people later on.
UPDATE
I was able to achieve the effect I desired, but the implementation is severely lacking. Here's what I did:
copied the templates for the views I wished to inline into templates/inline/
replaced {% extends base.html %} with {% extends inline/base.html %}
modified the view thus:
from django.core.urlresolvers import resolve
def inline(request, uri=''):
# get the view that would normally handle this request
view, args, kwargs = resolve('/' + uri)
# call the view
kwargs['request'] = request
template_response = view(*args, **kwargs)
response.template_name = os.path.join('inline', response.template_name)
return response
I don't like this solution because it will require those inline templates to be managed, being replaced/updated whenever apps in the project change, and so on. I would still dearly love a cleaner solution.
Update 2: Solution
chris-wesseling was 100% correct; a custom template loader was exactly what I needed. For posterity, here is my implementation.
app/loaders.py:
from django.conf import settings
from django.template.loader import BaseLoader
from django.template.base import TemplateDoesNotExist
import os
class BaseTemplateOverrideLoader(BaseLoader):
"""
Load templates from a specified subdirectory in the current app's directory.
"""
subdir = 'templates'
def load_template_source(self, template_name, template_dirs=None):
template_dir = os.path.join(
os.path.dirname(os.path.realpath(__file__)),
self.subdir
)
try:
t = os.path.join(template_dir, template_name)
with open(t, 'rb') as fp:
return (fp.read().decode(settings.FILE_CHARSET), template_dir)
except IOError:
pass
raise TemplateDoesNotExist(template_name)
class InlineTemplateLoader(BaseTemplateOverrideLoader):
"""
Override the location of base.html for inline views.
"""
is_usable = True
subdir = 'templates/inline'
# ... other custom override classes here ....
app/views/inline.py:
from django.conf import settings
from django.core.urlresolvers import resolve
from django.template import loader
def default(request, slug=None):
view, args, kwargs = resolve('/' + slug)
old_loaders = settings.TEMPLATE_LOADERS
# Temporarily insert the inline template loader into TEMPLATE_LOADERS;
# we must also force BaseLoader to reload all templates loaders since
# they are cached at compile time.
settings.TEMPLATE_LOADERS = ('app.loaders.InlineTemplateLoader', ) + \
settings.TEMPLATE_LOADERS
loader.template_source_loaders = None
# now call the original view that handles this request
kwargs['request'] = request
response = view(*args, **kwargs)
response_string = response.render()
# restore the template loaders to their original condition
settings.TEMPLATE_LOADERS = old_loaders
loader.template_source_loaders = None
return response_string
app/templates/inline/base.html:
{% comment %}
inline/base.html
-- render just the main content without any styles etc,
for loading as inline content via ajax or whatever.
{% endcomment %}
{% block main %}{% endblock %}
You can implement your own TemplateLoader and set it in your settings.TEMPLATE_LOADERS. You can have a look at this similar question for an approach of what you're trying to do.
Basically what you're looking for is a way to load base.html from a different location.
I am trying to learn more about Flask by building a CMS. I am using flask-admin to add the posts, images etc.
I have managed to override textarea with ckeditor. But I want to pass the paths of the images in the static folder to ckeditor image plugin.
I can't figure out how to pass parameters to my edit.html template.
Here's the code:
class TestAdmin(ModelView):
form_overrides = dict(text=forms.CustomTextAreaField)
create_template = 'edit.html'
edit_template = 'edit.html'
From the documentation of flask-admin I have found that _template_args can used to pass parameters to the template. But I can't figure out how.
What is the exact way to do that?
You have to override the views to change _template_args.
class TestAdmin(ModelView):
form_overrides = dict(text=forms.CustomTextAreaField)
create_template = 'edit.html'
edit_template = 'edit.html'
#expose('/edit/', methods=('GET', 'POST'))
def edit_view(self):
self._template_args['foo'] = 'bar'
return super(TestAdmin, self).edit_view()
If you want to pass some global value to templates, you can use a context_processor (http://flask.pocoo.org/docs/templating/#context-processors).
#app.context_processor
def inject_paths():
# you will be able to access {{ path1 }} and {{ path2 }} in templates
return dict(path1='x', path2='y')
To anyone finding this in 2023+ – you can do it now by overriding _get_list_extra_args method:
class YourView(ModelView):
list_template = "custom_template.html"
def _get_list_extra_args(self):
view_args = super()._get_list_extra_args()
view_args.extra_args["foo"] = "bar"
return view_args
Here we can control extra_args dict. Flask-Admin's index_view() passes it straight to the template as is, so you can modify it and use it in custom_template.html:
<div>
{{ extra_args.foo }} {# will render "bar" #}
</div>
# views.py
def like(request,option="food",restaurant = 1):
if request.is_ajax:
like = '%s_like' % str(option)
if 'restaurants' in request.session:
if restaurant not in request.session['restaurants']:
request.session['restaurants'][restaurant] = {}
x = request.session['restaurants'][restaurant].get(str(like),False)
if x:
return HttpResponse(False)
else:
request.session['restaurants'][restaurant][str(like)] = True
request.session.modified = True
else:
request.session['restaurants'] = {}
request.session.modified = True
I am using context_instance = RequestContext(request) so that session variable is available, while rendering response. My template:
{% if request.session.restaurants.rest.id.food_like %}
working
{% else %}
failed
{% endif %}
My view session key looks like this :
request.session["restaurants"][restaurant][like] = True
where restaurant is the restaurant id, and like could be one of " "food_like", "service_like", "special_like".
So how am i supposed to access it in my templates? For example if i use
request.session.restaurants.rest.id.food_like
it won't work for sure.
You might not have django.core.context_processors.request in your settings.TEMPLATE_CONTEXT_PROCESSORS.
You can try to print {{ request }} in the template, if it shows nothing then you don't have it.
You can also check it with ./manage.py shell:
from django.conf import settings
print settings.TEMPLATE_CONTEXT_PROCESSORS
If django.core.context_processors.request is not there, then copy TEMPLATE_CONTEXT_PROCESSORSfrom the shell output into your settings.py, and add django.core.context_processors.request to this list.
Complementing #jpic response.
Instead of copying the contents TEMPLATE_CONTEXT_PROCESSORS from shell you can do the following:
from django.conf import global_settings
TEMPLATE_CONTEXT_PROCESSORS = global_settings.TEMPLATE_CONTEXT_PROCESSORS + (
"django.core.context_processors.request",
)
In this way, your global settings will be preserved.
Make sure to keep the trailing comma so python could treat this as a tuple
This question already has answers here:
Can I access constants in settings.py from templates in Django?
(17 answers)
Closed 8 years ago.
I want to be able to put certain configuration information in my settings.py file - things like the site name, site url, etc.
If I do this, how can I then access those settings in templates?
Thanks
Let's say in your settings.py file you have:
SITE_URL='www.mydomain.tld/somewhere/'
SITE_NAME='My site'
If you need that in just one or two views:
from django.shortcuts import render_to_response
from django.conf import settings
def my_view(request, ...):
response_dict = {
'site_name': settings.SITE_NAME,
'site_url': settings.SITE_URL,
}
...
return render_to_response('my_template_dir/my_template.html', response_dict)
If you need to access these across a lot of apps and/or views, you can write a context processor to save code:
James has a tutorial on this
online.
Some useful information on the when and if of context processors is available on this very site
here.
Inside your my_context_processors.py file you would:
from django.conf import settings
def some_context_processor(request):
my_dict = {
'site_url': settings.SITE_URL,
'site_name': settings.SITE_NAME,
}
return my_dict
Back in your settings.py, activate it by doing:
TEMPLATE_CONTEXT_PROCESSORS = (
...
# yours
'my_context_processors.some_context_processor',
)
In your views.py, make a view use it like so:
from django.shortcuts import render_to_response
from django.template import RequestContext
def my_view(request, ...):
response_dict = RequestContext(request)
...
# you can still still add variables that specific only to this view
response_dict['some_var_only_in_this_view'] = 42
...
return render_to_response('my_template_dir/my_template.html', response_dict)
If using a class-based view:
#
# in settings.py
#
YOUR_CUSTOM_SETTING = 'some value'
#
# in views.py
#
from django.conf import settings #for getting settings vars
class YourView(DetailView): #assuming DetailView; whatever though
# ...
def get_context_data(self, **kwargs):
context = super(YourView, self).get_context_data(**kwargs)
context['YOUR_CUSTOM_SETTING'] = settings.YOUR_CUSTOM_SETTING
return context
#
# in your_template.html, reference the setting like any other context variable
#
{{ YOUR_CUSTOM_SETTING }}
If you only need a setting or two for a couple views, Context Processor may be overkill since it will add them to ALL views in your app. But if it's used in a lot of templates, Contest Processor is the way to go.
For the simple one off case just pass whatever setting you need from the view to the template:
from django.conf import settings
from django.shortcuts import render_to_response
def some_view(request):
val = settings.SAVED_SETTING
return render_to_response("index.html", {
'saved_setting':val
})
And access the setting in your template via:
{{ saved_setting }}