Opened 19 years ago

Closed 19 years ago

Last modified 17 years ago

#398 closed enhancement (wontfix)

[patch] {%define VAR as%}VALUE{%in%} tag

Reported by: jvr_django@… Owned by: Adrian Holovaty
Component: Template system Version:
Severity: normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I submit two patches.

The first patch modifies Parser.parse() to optionally pass its parse_until
context to the do_* callbacks. This allows template tags to have scopes
which are ended implicitly by the end of the enclosing scope.

The second patch defines a {% define VAR as %} VALUE {% in %} construct.
A typical use is:

        {% define title_var as%}
            {% block title %}The default title{% endblock %} 
        {% in %}
        <html>
        <head>
            <title>{{title_var}}</title>
        </head>
        <body>
            <h1>{{title_var}}</h1>
            ...

Here, by redefining the title block, a template can set the title BOTH in the <head> and the <body> of the page. Many other uses are possible. Note that this is not an attempt to turn the Django template system into a full-fledged programming language, it's just sometimes convenient to declare a name for a value and refer to it later.

I have put the define-tag in defaulttags.py because I feel that, as a
language construct, defining new variable bindings is at the same level as
FOR loops and IF statements.

If you do not agree, I hope you will still
accept the first patch, because it will allow me to put this define-tag
in my own apps and still use them with a standard Django installation.
(The define-tag uses the implicit ending feature introduced by the
first patch.)

Attachments (2)

implicit-end.diff​ (1.1 KB ) - added by jvr_django@… 19 years ago.
Patch for Parser.parse() to pass parse_until to do_* callbacks
define-tag.diff​ (2.7 KB ) - added by jvr_django@… 19 years ago.
patch for new {%define VAR as%}VALUE{%in%} tag

Download all attachments as: .zip

Change History (7)

by jvr_django@…, 19 years ago

Attachment: implicit-end.diff​ added

Patch for Parser.parse() to pass parse_until to do_* callbacks

by jvr_django@…, 19 years ago

Attachment: define-tag.diff​ added

patch for new {%define VAR as%}VALUE{%in%} tag

comment:1 by hugo <gb@…>, 19 years ago

why not {% define var %}<var value>{% in %}<body using definition>{% enddefine %} - that would be much more like other tags in the django template language. This "implicit end" looks ugly to me. And it would be a tag that's similar with the structure of if-else-endif for example.

comment:2 by mr_little, 19 years ago

I'd like to have another feature :)

{% set var_name1 as var_name2 %}

Example (in form):

{% set form.poll as f %}
label: {{ f }}
{% if f.errors %} {{ f.errors }} {% endif %}
... Other common things with f.* ...

Then copy-paste such element and change only first line

comment:3 by Joeri <jvr_django@…, 19 years ago

Hugo, for and if really need endfor and endif.
However, notice that {%extends%} for instance, doesn't.
It just takes control of the rest of the template.
If you define something, you are usually mostly thinking of what you are defining.
Where the definition ends does not really make a difference.
I find it a nuisance to have to go to the end of the file just because I added a definition at the beginning. However, you have a point, it should probably be possible to end the scope explictly
if needed.

mr_little, that is indeed a good idea. I'll see if I can create a new patch with support for something like {%define VAR as SOMETHING in%}BODY.

I explicitly avoided the word "set", because it suggests that I am somehow changing the context, rather than create a new, improved context. Hugo is right that including an {%enddefine%} would make that even more clear.

comment:4 by syntruth@…, 19 years ago

I'm a Smarty junkie/user, so bear with me... In a lot of my templates, I use the 'assign' function, which does what you are saying. I try to keep them to a minimal and set things within the site's actual code, to keep as much a separation between code and layout, but there *are* times when it is handy to have, to either simplify the readability of the template or to a temporary value if/when it is needed. (Sometimes, it is.)

I propose, to make it as simple as what Smarty has, but Django-like, rather like the 'cycle' function:

{% assign new_value as var_name %}

Then, if you wanted to hold a block chuck in a var: 

{% assign_block as var_name %}...{% endassign %}

comment:5 by Adrian Holovaty, 19 years ago

Resolution: → wontfix
Status: new → closed

I'm marking this as a wontfix because the template system isn't intended to be a full programming language. Of course, there's nothing stopping you from using this as a custom tag on your own.

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