Opened 11 years ago
Closed 7 years ago
#7153 closed Bug (fixed)
_resolve_lookup could do a better job of resolving callables and correctly catching silent_variable_failure exceptions
Reported by: | Owned by: | Chris Beaven | |
---|---|---|---|
Component: | Template system | Version: | master |
Severity: | Normal | Keywords: | template callable |
Cc: | daevaorn@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Right now callables are run only if they are object methods and dictionary lookup failed (which means a DictMixin
-like method wouldn't get called).
I don't think this is meant by design, so this patch moves the callable check at the end of _resolve_lookup(), making all callables passed to the template get run.
Attachments (4)
Change History (17)
Changed 11 years ago by
Attachment: | template_callable.diff added |
---|
comment:1 Changed 11 years ago by
Triage Stage: | Unreviewed → Ready for checkin |
---|
comment:2 Changed 11 years ago by
Needs tests: | set |
---|---|
Triage Stage: | Ready for checkin → Accepted |
comment:3 Changed 10 years ago by
Cc: | daevaorn@… added |
---|
comment:4 Changed 10 years ago by
Needs tests: | unset |
---|
Changed 10 years ago by
Attachment: | 7153.2.diff added |
---|
another test, and also adding catching silent variable failures everywhere (with tests)
comment:5 Changed 10 years ago by
Owner: | changed from nobody to Chris Beaven |
---|---|
Status: | new → assigned |
Summary: | Not all callables are run by the template system → _resolve_lookup could do a better job of resolving callables and correctly catching silent_variable_failure exceptions |
comment:7 Changed 8 years ago by
Patch needs improvement: | set |
---|
PS: you're doing a great job of triage, mk.
Changed 8 years ago by
Attachment: | 7153.3.diff added |
---|
comment:8 Changed 8 years ago by
Patch needs improvement: | unset |
---|
comment:9 Changed 8 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:10 Changed 8 years ago by
See #15057 for a patch with improved docs that describe the new behaviour.
comment:11 Changed 8 years ago by
comment:12 Changed 7 years ago by
Easy pickings: | unset |
---|---|
Resolution: | fixed |
Severity: | → Normal |
Status: | closed → reopened |
Type: | → Bug |
UI/UX: | unset |
This causes issues in any variable where the context lookup is a class. Rather than the class being returned, a bare instance is (assuming it can be instantiated without parameters). Is this expected behavior?
Here's how I ran into the issue: I drop a couple models into the context and do things with them in the template, namely passing the models in as filter arguments. In django 1.2.X, the classes are passed along intact into the filter. In 1.3.X, a bare instance of the class is passed in to the filter instead.
comment:13 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Near as I can tell the behavior you note is expected and documented as a 1.3 change: https://docs.djangoproject.com/en/1.3/releases/1.3/#callables-in-templates
Sounds like a reasonable proposition, but I'm not going to check in something like this without tests. Reminder to triagers - tests are not optional.