Opened 17 years ago
Closed 13 years ago
#6516 closed Bug (fixed)
Template extends bug when passing a template variable to extends tag
Reported by: | Wayne K. Werner | Owned by: | nobody |
---|---|---|---|
Component: | Template system | Version: | dev |
Severity: | Normal | Keywords: | extends template overwrite |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
This is loosely related to #5124, at least the problems lie in the same code where extends resolution occurs during rendering of the ExtendsNode.
Extended templates are fetched at the time that a child template is rendered. This is done to defer fetching the extended template in the case where a variable is used to specify the template, as a context must be available. This occurs in all cases, even when a hard coded string is passed, I assume to avoid having multiple ExtendsNode types in similar fashion to the IncludeNode types.
When an extended template is fetched, it is modified in two ways. First, if the extended template also extends and there is a block in the child template that does not exist in the parent, that block is appended to the parents ExtendsNode nodelist. Second, when the block does exist in the parent, it is inserted into the parent template and block in the parent template is attached to the parent attribute of the inserted block to support block.super.
In the two cases where a template name is passed, either as a variable or hard coded, this does not cause a problem, as the template is fetched from source and discarded after rendering. However in the case where an instantiated template is passed in, the passed in template is modified.
Rendering a template (or it's child) should make no changes to a template that will appear if it is rendered again.
I've included a file that demonstrates the case where the child block is inserted into the parent template with a link to it's super block. The other case should not be too hard to verify with a three layer heirarchy. I've also included a diff that does not fix the problem, but cleans up the code a bit and helps to clarify what is going on.
Attachments (2)
Change History (12)
by , 17 years ago
by , 17 years ago
Attachment: | cleanup.diff added |
---|
comment:2 by , 17 years ago
Component: | Uncategorized → Template system |
---|---|
Keywords: | extends template overwrite added |
comment:3 by , 17 years ago
Note: The bug where child blocks are inserted into the extended template with the extended templates block attached for super access constitutes a leak of BlockNode objects as well. Every time the template is rendered through the child template, the chain of block will continue to grow in the extended template.
comment:4 by , 17 years ago
cleanup.diff needs to be reconciled with #5124, I will do so when it settles down
comment:5 by , 17 years ago
Whoops! Sorry. Meant to attach to different ticket. Ignore contains_nontext_2.diff!
comment:6 by , 16 years ago
Triage Stage: | Unreviewed → Accepted |
---|
If I'm reading this correctly, the correct approach is to make a copy of the parent template when it's a template object. Yes?
comment:7 by , 14 years ago
Type: | → Bug |
---|
comment:8 by , 14 years ago
Severity: | → Normal |
---|
comment:9 by , 13 years ago
Easy pickings: | unset |
---|---|
Triage Stage: | Accepted → Unreviewed |
UI/UX: | unset |
Just run test.py on django trunk, the result seems to be correct:
$ python test.py content block in t1 is modified by rendering through t2 t1.render() t1 t2.render() t2t1 t1.render() t1 content block added to t2 when rendering through t3 t1.render() t1 t2.render() t1 t3.render() t3 t2.render() t1
IMO the bug has already been fixed, please review it (in case i didn't get the point).
comment:10 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I confirm the bug was fixed as a side effect of r11862.
Demonstration of the bug.