Opened 5 years ago

Closed 3 years ago

Last modified 3 years ago

#14502 closed New feature (fixed)

Feature: escape hatch for colliding template syntax in Django templates

Reported by: dgouldin Owned by: aaugustin
Component: Template system Version:
Severity: Normal Keywords:
Cc: dgouldin@…, jdunck@…, davidnovakovic@…, kmike84@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

As discussed in django-developers:

http://groups.google.com/group/django-developers/browse_thread/thread/e914638d8fe859de

There is a need for a template block tag which renders template syntax characters within the block as normal text. This serves as an escape hatch to avoid syntax collisions when using a template language meant to be rendered on the client, not the server. A potential implementation is attached.

Attachments (2)

noparse.py (911 bytes) - added by dgouldin 5 years ago.
14502-no-customizable-end-tag.patch (3.4 KB) - added by aaugustin 3 years ago.

Download all attachments as: .zip

Change History (24)

Changed 5 years ago by dgouldin

comment:1 Changed 5 years ago by dgouldin

  • Cc dgouldin@… added
  • Needs documentation set
  • Needs tests set
  • Patch needs improvement unset

comment:2 Changed 5 years ago by jdunck

  • Patch needs improvement set
  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 5 years ago by jdunck

  • Owner changed from nobody to jdunck
  • Status changed from new to assigned

comment:4 Changed 5 years ago by jdunck

  • Owner changed from jdunck to nobody
  • Status changed from assigned to new

comment:5 Changed 5 years ago by jdunck

  • Has patch set

comment:6 Changed 5 years ago by jdunck

  • Cc jdunck@… added

comment:7 Changed 5 years ago by floguy

I don't think this patch is quite sufficient because it can actually change the contents of the text in the noparse block. Specifically, it won't preserve whitespace within things that it interprets as blocks or variables.

However, I don't think it's going to be possible to escape out of parsing using the usual templatetag constructs, because it's already tokenized and parsed by the time it's handed off to the node.

Maybe a pre-processing step that happens before everything else is in order?

comment:8 Changed 5 years ago by jdunck

Eric, to be clear, are you referring to Lexer.create_token using .strip?

If so, I see the need for that (later context[var_name] kinds of lookups), but perhaps tokens could hang on to their raw contents? Or perhaps a final step in Parser could perform those strips after nodes have been constructed? (Neither sounds ideal...)

comment:9 Changed 5 years ago by dpn

  • Cc davidnovakovic@… added

comment:10 Changed 4 years ago by julien

  • Severity set to Normal
  • Type set to New feature

comment:11 Changed 4 years ago by aaugustin

  • Easy pickings unset
  • UI/UX unset

#16318 was a duplicate. It contains an alternative implementation.

Another discussion : http://groups.google.com/group/django-developers/browse_thread/thread/eda0e9187adcbe36

"verbatim" is a better name than "noparse" IMO — that's how people call this feature spontaneously.

comment:12 Changed 4 years ago by kmike

  • Cc kmike84@… added

comment:13 Changed 3 years ago by SmileyChris

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Accepted to Ready for checkin
  • Version 1.2 deleted

comment:14 Changed 3 years ago by Aymeric Augustin <aymeric.augustin@…>

  • Resolution set to fixed
  • Status changed from new to closed

In [4464bbba15d50ed32beb5995c13d26791ca61fe4]:

Fixed #14502 -- Added a verbatim template tag.

Thanks SmileyChris for the patch.

comment:15 Changed 3 years ago by jezdez

I'm not sure I understand the purpose of the alternate closing tag, can you elaborate (in the docs and here) why this was needed to be added (as it's a rather extensive departure of a core tag)?

comment:16 Changed 3 years ago by jezdez

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Triage Stage changed from Ready for checkin to Design decision needed

comment:17 Changed 3 years ago by aaugustin

  • Has patch unset

So, I just reviewed the mailing list discussions on this topic.

Clearly there's some demand for a verbatim tag, and it should be implemented in the template engine itself (because the verbatim content shouldn't be parsed).

Personally, I'd prefer if the verbatim text could contain any text -- including {% endverbatim %} -- otherwise someone's going to notice and complain. But we could very well live without this possibility: there's always the (ugly) alternative of splitting the {% endverbatim %} to output, like this:

{% verbatim %}bla bla {% end{% endverbatim %}{% verbatim %}verbatim %} bla bla{% endverbatim %}

For the record, the alternate closing tag was suggested on the mailing list (and also in a few follow up posts). Chris implemented it and considered his patch ready to go, basically endorsing the idea. The implementation looked reasonable to me, so I went ahead and committed the patch.

comment:18 Changed 3 years ago by aaugustin

  • Owner changed from nobody to aaugustin
  • Status changed from reopened to new

Assigning to myself so I don't forget to resolve this, one way or another.

comment:19 Changed 3 years ago by aaugustin

  • Triage Stage changed from Design decision needed to Accepted

Following a discussion with Jannis, here's a patch that removes the overridable end tag. It's trading debatable benefits for some complexity and doesn't fit so well with the rest of the template language. Specifically, it could make refactoring the template language significantly harder.

If we absolutely wanted to keep a way to escape {% endverbatim %}, I'd suggest using {% verbatim blahblah %}...{% endverbatim blahblah %}, similar to what the {% block %} tag does.

Changed 3 years ago by aaugustin

comment:20 Changed 3 years ago by Chris Beaven <smileychris@…>

  • Resolution set to fixed
  • Status changed from new to closed

In [c57ba673312cb5774d544353044e2182b6223040]:

Fixed #14502 again -- saner verbatim closing token

Previously, the closing token for the verbatim tag was specified as the
first argument of the opening token. As pointed out by Jannis, this is
a rather major departure from the core tag standard.

The new method reflects how you can give a specific closing name to
{% block %} tags.

comment:21 Changed 3 years ago by anonymous

Jannis: if you're still not happy with how this looks, then I'm fine with just removing this "edge case" and never allowing for having {% endverbatim %} unrendered.

comment:22 Changed 3 years ago by SmileyChris

(says me)

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