3👍
The second argument to render_to_response()
must be a dictionary. You are passing in a RequestContext()
instead.
Remove the RequestContext()
object and make variables
just a dictionary:
variables = {
'fresh_locations': fresh_data_locations,
'webalert_locations': webalert_locations,
'locations_reporting': reporting_locations,
'locations_not_reporting': locations_not_reporting,
'inalarm_count': inalarm_count,
'inalarm_stores': inalarm_stores_qs,
'workspace_count': workspace_count,
'user_profile': user_profile,
}
0👍
This is because the render_to_response() and also render() shortcuts will automatically apply RequestContext on the context variables (your variables dir). Its a typo for sure, but why did it work before you ask?
It would have worked up to 1.6, but the implementation RequestContext in django.template.context has changed in 1.7. It was broken down to be more object oriented and optimized to make it more efficient. The history is here, I think it was
https://github.com/django/django/commits/master/django/template/context.py
This commit in particular optimized RequestContext:
https://github.com/django/django/commit/8d473b2c54035cbcd3aacef0cb83a9769cd05ad3
Here is how to re-produce the error:
>>> from django.template import RequestContext
>>> from django.test.client import RequestFactory
>>> request_factory = RequestFactory()
>>> request = request_factory.get('www.google.com')
>>> fresh_data_locations, webalert_locations, reporting_locations, locations_not_reporting, inalarm_count, inalarm_stores_qs, workspace_count, user_profile = '', '', '', '', '', '', '', ''
>>> variables = RequestContext(request, {
... 'fresh_locations': fresh_data_locations,
... 'webalert_locations': webalert_locations,
... 'locations_reporting': reporting_locations,
... 'locations_not_reporting': locations_not_reporting,
... 'inalarm_count': inalarm_count,
... 'inalarm_stores': inalarm_stores_qs,
... 'workspace_count': workspace_count,
... 'user_profile': user_profile,
... })
>>> variables
[{'False': False, 'None': None, 'True': True}, {'workspace_count': '', 'locations_not_reporting': '', 'fresh_locations': '', 'inalarm_stores': '', 'locations_reporting': '', 'webalert_locations': '', 'user_profile': '', 'inalarm_count': ''}, {u'csrf_token': <django.utils.functional.__proxy__ object at 0x10439fcd0>, u'sql_queries': [], 'perms': <django.contrib.auth.context_processors.PermWrapper object at 0x10439fe50>, 'messages': [], u'request': <WSGIRequest
path:/www.google.com,
GET:<QueryDict: {}>,
POST:<QueryDict: {}>,
COOKIES:{},
META:{u'HTTP_COOKIE': u'',
u'PATH_INFO': u'www.google.com',
u'QUERY_STRING': '',
u'REMOTE_ADDR': '127.0.0.1',
u'REQUEST_METHOD': 'GET',
u'SCRIPT_NAME': u'',
u'SERVER_NAME': 'testserver',
u'SERVER_PORT': '80',
u'SERVER_PROTOCOL': 'HTTP/1.1',
u'wsgi.errors': <_io.BytesIO object at 0x1042fce30>,
u'wsgi.input': <django.test.client.FakePayload object at 0x104391550>,
u'wsgi.multiprocess': True,
u'wsgi.multithread': False,
u'wsgi.run_once': False,
u'wsgi.url_scheme': 'http',
u'wsgi.version': (1, 0)}>, 'api_header': {'content-type': 'application/json', 'Authorization': 'YmFrZXItYXBpOlVuaW9uMTIz'}, u'STATIC_URL': '/static/', u'LANGUAGES': (('en', 'English'),), 'api_address': 'http://69.164.69.214/BakerPublic/api', 'user': <django.contrib.auth.models.AnonymousUser object at 0x10439fe10>, u'LANGUAGE_CODE': u'en-us', u'debug': True, 'DEFAULT_MESSAGE_LEVELS': {'DEBUG': 10, 'INFO': 20, 'WARNING': 30, 'SUCCESS': 25, 'ERROR': 40}, u'LANGUAGE_BIDI': False, u'MEDIA_URL': '/media/'}]
>>> type(variables)
<class 'django.template.context.RequestContext'>
>>> dict(variables)
Traceback (most recent call last):
File "<console>", line 1, in <module>
ValueError: dictionary update sequence element #0 has length 15; 2 is required
So with django 1.6 dir() function returned without error but with the 1.7 implementation it fails. Just one of those things that worked by you can almost say coincidence prior to 1.7.
When using class based views from django.views.generic, a lot of this stuff is just done for you. If you look at TemplateView, you will see that it inherits render_to_response method from TemplateResponseMixin which uses TemplateResponse that does all this stuff. Also check out ContextMixin, which has the get_context_data method. The cleanest way I think to pass context data to the template. More on generic / class based views here.
- [Django]-SubfieldBase has been deprecated. Use Field.from_db_value instead
- [Django]-Removing unused lookup_field generated from router on viewset
- [Django]-Jwt.encode fails with "Object of type 'bytes' is not JSON serializable"
- [Django]-Django-Tagging – count and ordering top "tags" (Is there a cleaner solution to mine?)