Opened 8 years ago

Closed 3 years ago

#9256 closed Cleanup/optimization (wontfix)

Let the template parser remember it's root nodelist

Reported by: Chris Beaven Owned by: Chris Beaven
Component: Template system Version:
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

This is useful if tags want to parse the templates root nodelist (built up to the current parsing point) for some reason.

As a specific example, I've got a {% repeatblock %} tag (which duplicates the nodelist of an existing block) which needs this functionality.

Attachments (1)

root_nodelist.diff (680 bytes) - added by Chris Beaven 8 years ago.

Download all attachments as: .zip

Change History (12)

Changed 8 years ago by Chris Beaven

Attachment: root_nodelist.diff added

comment:1 Changed 8 years ago by Chris Beaven

Needs documentation: unset
Needs tests: unset
Owner: changed from nobody to Chris Beaven
Patch needs improvement: unset
Status: newassigned

comment:2 Changed 8 years ago by Jacob

Triage Stage: UnreviewedDesign decision needed

I don't quite understand what this does -- can you give me more details about why this is important?

comment:3 Changed 8 years ago by Chris Beaven

Sure. The problem I was facing is that my tag needed to find a separate node (generated by previously parsed tokens).

Currently, the parser creates a root nodelist when starts parsing the tokens (nodelist = self.create_nodelist()) but there is no way to access this nodelist because it is only a local variable.
By allowing this to be an instance variable it allows tags (which accept the parser instance as one of the arguments) to inspect - and modify if necessary - the nodelist created so far.

Specifically, my {% repeatblock %} tag was taking on the suggestion of Malcolm regarding allowing a the contents of a block node to be used more than once in an old discussion (which, in certain cases, would still be useful)

comment:4 Changed 7 years ago by Chris Beaven

Version: 1.0

I couldn't find my old tag, so I remade it and put it here for an example: http://github.com/SmileyChris/django-repeatblock

comment:5 Changed 7 years ago by belgabor

Unfortunately this falls apart if the block and repeatblock tag occur in the same block-level tag (eg autoescape). I'm not sure if there is an easy fix :/

comment:6 Changed 5 years ago by Chris Beaven

Severity: Normal
Type: Cleanup/optimization

comment:7 Changed 5 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:8 Changed 5 years ago by Aymeric Augustin

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:9 Changed 3 years ago by Jacob

Triage Stage: Design decision neededAccepted

comment:10 Changed 3 years ago by anonymous

Actually if the reason behind such a change is just the repeatblock tag, I believe it's quite unnecessary as there is a solution for this particular problem -- goo.gl/caOOu

comment:11 Changed 3 years ago by Chris Beaven

Resolution: wontfix
Status: assignedclosed

It's not the reason, that was just an example of the usefulness of such a pointer.

But it's not something I've heard any requests for, and since I opened it, I'll close it.

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