Opened 7 years ago

Closed 2 years ago

#9256 closed Cleanup/optimization (wontfix)

Let the template parser remember it's root nodelist

Reported by: SmileyChris Owned by: SmileyChris
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 SmileyChris 7 years ago.

Download all attachments as: .zip

Change History (12)

Changed 7 years ago by SmileyChris

comment:1 Changed 7 years ago by SmileyChris

  • Needs documentation unset
  • Needs tests unset
  • Owner changed from nobody to SmileyChris
  • Patch needs improvement unset
  • Status changed from new to assigned

comment:2 Changed 6 years ago by jacob

  • Triage Stage changed from Unreviewed to Design decision needed

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

comment:3 Changed 6 years ago by SmileyChris

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 5 years ago by SmileyChris

  • Version 1.0 deleted

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 5 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 4 years ago by SmileyChris

  • Severity set to Normal
  • Type set to Cleanup/optimization

comment:7 Changed 3 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:8 Changed 3 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:9 Changed 2 years ago by jacob

  • Triage Stage changed from Design decision needed to Accepted

comment:10 Changed 2 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 2 years ago by SmileyChris

  • Resolution set to wontfix
  • Status changed from assigned to closed

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