#17778 closed Bug (fixed)
RequestContext methods pollute template variables
Reported by: | KyleMac | Owned by: | |
---|---|---|---|
Component: | Template system | Version: | 1.4-beta-1 |
Severity: | Normal | Keywords: | sprint2013 |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Imagine the following simple view:
def index(request): return render_to_response('template.html', { 'myvar': 'My Variable' }, context_instance=RequestContext(request))
And the following simple template:
{{ myvar }} is {% if not new %}not {% endif %}new.
The output will always be:
My Variable is new.
This is because django.template.base.Variable._resolve_lookup is finding the new() method on RequestContext which is then forced to a string resulting in "[{}]".
If you're asking why you want to access a variable that the view never sets then the reason is that this situation can occur when views are including or extending the same template.
Attachments (2)
Change History (9)
by , 13 years ago
Attachment: | 17778-testcase.patch added |
---|
comment:1 by , 13 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 12 years ago
Keywords: | sprint2013 added |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:3 by , 12 years ago
Has patch: | set |
---|---|
Owner: | removed |
Status: | assigned → new |
Triage Stage: | Accepted → Design decision needed |
To solve this we have to explicitly disallow attributes on the context. Or at least disallow class attributes.
I attached a patch that does the last option. But I think a design decision is needed here.
comment:4 by , 12 years ago
Triage Stage: | Design decision needed → Accepted |
---|
Under which circumstances would Django try to access attributes on the context?
comment:6 by , 11 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
I just attached a test case that demonstrates the problem.