Opened 16 years ago
Closed 10 years ago
#12212 closed Bug (fixed)
inclusion_tag behavior on variable not in context is inconsistent
| Reported by: | Leo Shklovskii | Owned by: | |
|---|---|---|---|
| Component: | Template system | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | yes |
| Easy pickings: | no | UI/UX: | no |
Description
If you use a variable that doesn't exist in the context as an argument to a template tag created with @register.inclusion_tag() the tag throws a VariableDoesNotExist which is inconsistent with the way that all other tags behave in the template language.
I would expect that the wrapping inclusion_tag() code just passes None to the wrapped templatetag for the argument rather than blowing up.
Attachments (1)
Change History (10)
comment:1 by , 16 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
by , 16 years ago
| Attachment: | 12212.patch added |
|---|
comment:2 by , 16 years ago
| Has patch: | set |
|---|---|
| milestone: | → 1.2 |
| Owner: | changed from to |
| Status: | new → assigned |
There's two ways I could see of solving this: document the fact that they do this or fix the behavior. The former is relatively simple if the core committers decide its better so the attached patch does the latter.
Along the way I noticed that simple_tag has the same issue and fixed it as well. The patch includes doc changes and sets up tests for simple_tag and inclusion_tag.
Adding this for consideration into 1.2.
comment:4 by , 15 years ago
| milestone: | 1.3 |
|---|---|
| Severity: | → Normal |
| Type: | → Bug |
comment:5 by , 15 years ago
| Easy pickings: | unset |
|---|---|
| Patch needs improvement: | set |
12212.patch fails to apply cleanly on to trunk
comment:6 by , 14 years ago
| Owner: | removed |
|---|---|
| Status: | assigned → new |
| UI/UX: | unset |
comment:7 by , 14 years ago
| milestone: | → 1.4 |
|---|
comment:9 by , 10 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I tested as far back as Django 1.4 and {% custom_tag nonexistent %} passes an empty string for nonexistent to the tag so it seems this has been fixed unless I misunderstood the issue.
Patch against r12699