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?) On 8 August 2018 at 15:42, Matthew Pava <matthew.p...@iss.com> wrote: > 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', > ], > }, > }, > ] > > > > -----Original Message----- > From: django-users@googlegroups.com [mailto:django-users@googlegroups.com] On > Behalf Of Hanne Moa > Sent: Wednesday, August 8, 2018 7:56 AM > To: django-users@googlegroups.com > Subject: Upgrading from Django 1.7: render_to_response and context_instance > > 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) > ) > > ) > > -- > 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+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@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. > > -- > 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+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@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/2ad6339f81e14a7bb7ab28a35e07470e%40ISS1.ISS.LOCAL. > For more options, visit https://groups.google.com/d/optout. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to django-users@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%3Drrdr%3DCWT9%3D2TpFei1Rm0TgXBCp1o3RH8ZmSMtZNtnF3b%2Bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
