Upgrading from Django 1.7: render_to_response and context_instance

[Hanne Moa]

I'm upgrading a rather large code base from django 1.7, with the
ultimate goal to have it run on 1.11, as the code isn't fully verified
to run on python 3 yet.

I'm replacing `render_to_response()` with `render()` everywhere a
RequestContext is used, and came upon this (simplified) oddity:

return render_to_response(
template,
{'important': 1},
context_instance=RequestContext(
request, processors=[important_processor])
)

What important_processor() does is return a dictionary {''important":
FOO} where the value of FOO depends on something in the request.

Many other views' render_to_response() had this as its
context_instance, but they did not define 'important" in the
dictionary before the context_instance, so I replaced them with:

return render(
request,
template,
important_processor(request) + {'whatever': 'was', 'in': 'here'}
)

In the first example I'm having some trouble figuring out which value
for "important" is visible to the template: is it 1, or whatever
important_processor() generates?

If I print what I think is context that is used to render the
template, I get a list of multiple dictionaries. The last two both
have a "important"-key, but with different values. {'important': 1}
comes first of the two.

I am neck deep in the template rendering code right now and I'm quite lost.


HM


(For statistics' sake , some 95% of the render_to_response()s looked like this:

return render_to_response(
some_template,
some_dict,
context_instance=RequestContext(request)
)

)

[Matthew Pava]

If you are simply adding something to most every request, I would add a context processor in the TEMPLATE settings.

Check out https://docs.djangoproject.com/en/2.1/topics/templates/#context-processors

In this example, I have an app called general. Within that is a py file called context_processors. In that file is a function called extra_context that takes request as an argument. I just return a dictionary that all of my templates have access to.

TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [
# insert your TEMPLATE_DIRS here
os.path.join(BASE_DIR, 'templates'),
],
'APP_DIRS': True,
'OPTIONS': {
'debug': True,
'context_processors': [
# Insert your TEMPLATE_CONTEXT_PROCESSORS here or use this
# list if you haven't customized them:
'django.contrib.auth.context_processors.auth',
'django.template.context_processors.debug',
'django.template.context_processors.i18n',
'django.template.context_processors.media',
'django.template.context_processors.static',
'django.template.context_processors.tz',
'django.contrib.messages.context_processors.messages',
'django.template.context_processors.request',
'general.context_processors.extra_context',
],
},
},
]

--
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CACQ%3DrrfLhhHrtKVSvcwJ7SmNyePdybEhO50%2Bepd8hcuLEG5sgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Hanne Moa]

This is only used in one app, and one views.py out of 38. There's only
this one views.py remaining that uses render_to_response with
context_instance. If this was modern Django code written by me I would
have used class-based views and a mixin modifying get_context_data
(Thank $deity for CBVs).

There is one other view that used something similar, through a
subclass of RequestContext instead of a local context processor. It
added two keys to every context in every view for that app/views.py.
There was never any overlap with what was put in the explicit context
so the fix was almost seddable.

This is a very lava flow heavy project so asking the original
developer about what the point was is out, and the point isn't
commented/documented either. (But who remembers 5 year old code at
that level of detail anyway?)

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/2ad6339f81e14a7bb7ab28a35e07470e%40ISS1.ISS.LOCAL.