Opened 17 years ago

Closed 14 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)

test.py (894 bytes ) - added by Wayne K. Werner 17 years ago.
Demonstration of the bug.
cleanup.diff (11.1 KB ) - added by Wayne K. Werner 17 years ago.

Download all attachments as: .zip

Change History (12)

by Wayne K. Werner, 17 years ago

Attachment: test.py added

Demonstration of the bug.

by Wayne K. Werner, 17 years ago

Attachment: cleanup.diff added

comment:1 by Wayne K. Werner, 17 years ago

The included demonstration code demonstrates both kinds of errors.

comment:2 by Wayne K. Werner, 17 years ago

Component: UncategorizedTemplate system
Keywords: extends template overwrite added

comment:3 by Wayne K. Werner, 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 Wayne K. Werner, 17 years ago

cleanup.diff needs to be reconciled with #5124, I will do so when it settles down

comment:5 by Wayne K. Werner, 17 years ago

Whoops! Sorry. Meant to attach to different ticket. Ignore contains_nontext_2.diff!

comment:6 by Jacob, 17 years ago

Triage Stage: UnreviewedAccepted

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 Julien Phalip, 14 years ago

Type: Bug

comment:8 by Julien Phalip, 14 years ago

Severity: Normal

comment:9 by Vladimir Moskva, 14 years ago

Easy pickings: unset
Triage Stage: AcceptedUnreviewed
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 Aymeric Augustin, 14 years ago

Resolution: fixed
Status: newclosed

I confirm the bug was fixed as a side effect of r11862.

Note: See TracTickets for help on using tickets.
Back to Top