Opened 17 years ago
Closed 13 years ago
#5831 closed Bug (fixed)
Template Debug highlights wrong {% for %} tag
Reported by: | Owned by: | Vladimir Moskva | |
---|---|---|---|
Component: | Template system | Version: | dev |
Severity: | Normal | Keywords: | debug for toplevel nesting |
Cc: | m@… | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
When an exception happens within a for tag's head, the error source is assigned always assigned to the top-level for loop, even if the erroneous for tag is nested.
Example:
{% for a in as %} {% for b in a.bs %} {% for c in b.relatedobject_set %} {{ c.foo }} {% endfor %} {% endfor %} {% endfor %}
The error here is at "b.relatedobject_set", which should be "b.relatedobject_set.all" (assuming b is a model related to a model releatedobject).
As is, the template debug system marks the top level for tag, "{% for a in as %}", as being the point of error. The correct place to mark is the for tag where the error happened.
Attached is a patch that fixes this. I'm not familiar with Django's tag tests, so I can't include any, but would be happy to learn and supply some if it is agreed that this is a correct fix.
Attachments (2)
Change History (16)
by , 17 years ago
Attachment: | forloop.nodelist.patch added |
---|
comment:1 by , 17 years ago
Summary: | Template Debug only highlights wrong {% for %} tag → Template Debug highlights wrong {% for %} tag |
---|
comment:2 by , 17 years ago
#6468 marked as a dup. It also has a template example that shows the bug.
comment:3 by , 17 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:4 by , 16 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:6 by , 16 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:7 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Bug |
comment:8 by , 14 years ago
Easy pickings: | unset |
---|---|
Needs tests: | set |
Patch needs improvement: | set |
Confirming that this issue is still occurring. Needs tests to take this further. The patch also needs improvement as the ForNode
's code has changed since 4 years ago.
comment:9 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
UI/UX: | unset |
comment:10 by , 14 years ago
Needs tests: | unset |
---|---|
Patch needs improvement: | unset |
django.template.defaulttags.ForNode.render method calls .render method for subnodes and there loses the information which exactly node caused the error, that's why DebugNodeList always marked the first forloop of nested as which caused the error.
I've made a patch which adds source of the the node that actually caused the error as the exception's attribute, which is later intercepted by DebugNodeList.render method.
Tests are included.
comment:11 by , 14 years ago
Chanded order if and try..except statements. Now try..except is performed only when settings.TEMPLATE_DEBUG is true, so it shouldn't slower rendering with debugger disabled.
comment:12 by , 14 years ago
Chanded order if and try..except statements. Now try..except is performed only when settings.TEMPLATE_DEBUG is true, so it shouldn't slower rendering with debugger disabled.
comment:13 by , 14 years ago
Cc: | added |
---|
comment:14 by , 14 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
patch against SVN revision 6626