Support for arguments on intermediate tag tokens (ex. {% if arg %}{% elif arg %}{% endif %})

[Eric Van Dewoestine <ervandew@…>]

Patch based on development version 4051.

Currently the template functionality prevents creation of tags which have intermediate tags requiring arguments.

For instance:

{% myif arg %}
  first block
{% elif arg %}  <-- current version would fail to parse this correctly because of the arg
  second block
{% endmyif %}

The attached patch removes this restriction.

[Eric Van Dewoestine <ervandew@…>]

note patch is for file django/template/init.py.diff

[Eric Van Dewoestine <ervandew@…>]

Just stumbled on ​http://code.djangoproject.com/ticket/3090 ... not sure which one is more or less correct, but as long as the referenced example in each is supported, I'm happy.

[Russell Keith-Magee]

This may be a duplicate of #3090, but this ticket describes the problem much better. Reopening.

[Julien Phalip]

See also #8296 for a similar issue but formulated differently.

[Daniel Ring]

patch breaks regressiontests.templates 'namedendblocks0[234]'

[Daniel Ring]

The patch just added breaks the regressiontests.templates 'namedendblocks0?' by failing to raise TemplateSyntaxError when {% endblock %} tags are out of order. (Since endblock tags are the only (core) tags where the endtag has an argument.)

So two possibilities are:

1. remove those tests - seems okay to me, since the named-endblock tags are for readability anyway, rather than providing functionality; also, named endblocks are only used (at least in trunk) in contrib.gis javascripts.
2. make additional changes in template.loader_tags.do_block to force strict checking of endblock tags there

Which would be the desired route? Or something altogether different?

[Adrian Holovaty]

I'm fine with removing those named-end-block tests. I agree that named endblock tags are just for readability, anyway.

[cwebber]

I removed those named-end-block tests and also added {% elif %} tag support (yay, {% elif %} tags is a major feature!)

[cwebber]

Docs for the new {% elif %} tag

[cwebber]

Added docs for the {% elif %} tag.

[cwebber]

Django {% elif %} tag support (now with docs in the same patch)

[Malcolm Tredinnick]

Hmm... so this is two different things in one patch: (1) is allowing args on the intermediate tag, (2) changing if tag to include elif. We might want (1) without (2), hence our usual insistence on one feature per ticket.

That being said, the patch looks reasonable. However, the change to the tests to remove the unbalanced blocks test is bad. You are removing tests that check for something bad happening. If this patch doesn't let those tests still fail, the patch is broken. If it doesn't affect those tests, they should remain. Either way, this isn't ready for checkin yet. I'll add "needs tests" to the flags for this reason, in case somebody is looking for test related work. It doesn't need new tests, just those deleted "extra endblock" tests restored, please.

[Matthias Kestenholz]

A differentiation between intermediate tags which accept arguments and tags who don't seems to be necessary to support this use case properly (without breaking backwards-compatibility or deleting tests).

The attached patch adds another argument to django.template.Parser.parse; parse_until is complemented by parse_until_args_allowed. The included if-tag supporting {% elif %} makes use of this. The previously deleted "extra endblock" tests have been restored and they pass, as they should.

The documentation about writing custom tags would have to be extended for this, though.

[Chris Beaven]

An alternative to adding a parse_until_args_allowed argument

[Cal Leeming]

Guys - any idea when this might make it into a release??

Cal

[Aymeric Augustin]

#17348 was created to discuss the addition of {% elif %} — as pointed out by Malcolm these are two different (however related) features.

[Aymeric Augustin]

Here are some implementation details of the Parser class that I had to look up in the source in order to understand this ticket.

An instance of Parser holds a list of tokens — the output of Lexer.tokenize — in its tokens instance variable. Its parse method builds a list of nodes (nodelist) by repeatedly popping the first token, compiling it, and appending to nodelist appropriate nodes.

parse terminates:

• when it reaches the end of the token stream;
• when it receives a block token whose content is found in parse_until (when it was called with a parse_until argument).

parse_until is used by tags that use final (or intermediary) tags, like {% block ... %} {% endblock %}, or {% for ..%} {% empty %} {% endfor %}. However, the current implementation requires that the exact content of the final (or intermediary) tag is known by the time the initial tag is compiled. This makes it impossible to have variable arguments on the intermediary tag.

This feature is used to reject unmatched block/endblock tags: {% block foo %}{% endblock bar %}. I think this check could be delegated to the block tag itself. The alternative is to use Chris' technique — looking for an exact match by default, and for a prefix match for elements that end with a space — but it feels hackish.

[Aymeric Augustin]

Attached patch implement changes accept arguments on intermediary or final tags in a backwards compatible way.

This is exercised by the new implementation of the {% block %} tag. Namely, template test namedendblocks04 breaks if the changes in django/template/loader_tags.py are omitted.

[Aymeric Augustin]

In [17186]:

Fixed #3100 -- Added support for arguments on intermediate tag tokens.

[Aymeric Augustin]

In [17187]:

Fixed #17348 -- Implemented {% elif %}. Refs #3100.