I'd be strongly -1 on anything that makes template language look more like m4!
Having said that, I can see this being useful. We use templates to
render most kinds of output. When we render text emails, the newlines
and indentation are particularly important, as everything gets
displayed 'as-is' by the client, and having a template that is
readable and also renders correctly is tricky.
Generally where this happens is where we open a block level tag, and
would then normally have a newline for readability, but cannot due to
us not wanting a newline to appear. This could be addressed by having
a different open/close tag for tags which chomp the preceeding/next
character if it is a newline. Eg:
In your folder are:
{^ for item in folder ^}
{{ item }},
{^ endfor ^}
This would render as "In your folder are: item1,item2,item3,"
Changing some of the carets:
In your folder are:
{% for item in folder ^}
{{ item }},
{^ endfor %}
This would render as "In your folder are:\nitem1,item2,item3,\n"
I'm not 100% convinced though.
Cheers
Tom
Fwiw, I had a different solution to this problem once, which I implemented
in a project using jinja to generate configuration files:
1. Prior to processing the template, replace all blank lines with a
tag (e.g. "BLANKLINE").
2. After processing the template, remove all blank lines.
3. Remove all instances of BLANKLINE, which restores the blank lines
the author intended.
This works remarkably well, and the output is easy to predict by the
template author. For the case you mentioned above, you would still need to
join the lines, though:
{% for item in folder %}{{ item }},{% endfor %}
Aron
foo bar {##}baz
For this (avoiding newlines) the currently discussed multiline tags would work pretty well too without adding more cruft to the template language:
foo bar {##}baz
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Jinja implements whitespace control by putting a minus sign after/before the % in a tag - http://jinja.pocoo.org/docs/templates/#whitespace-control - I haven't tried it myself, but it looks like {% tag -%} is equivalent to your {% tag %}{# .
Adding more symbols to existing tags (e.g. {^ for x in y ^} or {% for
x in y -%}), multi-line comment tags that don't actually include a
comment, and half baked comment tags (where the closing tag is
assumed) are all going to make templates uglier, and harder to read.
{% stripwhitespace on %} at the top of your template, followed by {% for
x in y %}? I think the latter is far more readable.
My ideal solution is not to add new ways to mark each individual
template tag that should have surrounding white space stripped, but to
simply enable the removal of lines that have only block tags and no
actual content. 99% of the time this is the right thing to do, and we
just need a deprecation path and new template tag so that template
authors can opt-in to the new behaviour now.
In most situations white space matters:
{{ user.lastname }} {{ user.firstname }}
foo bar {##}baz
You just made a strong argument against multiline tags: I wouldn't want to see them abused this way!
Agreed. When I started using Django templates I was very surprised at
the output I was seeing.
After a while I realised that the thing that suprised me was that
newlines were being output for what I considered to be just
'directives' -- that is, lines that contained tags, not content. For
example, {% if %} and {% endif %} tags on lines by themselves.
Honestly, my use case then was to make my HTML look pretty, so was
able to let it go pretty easily. Recently however I used the template
system to produce an email with a textual pricing table, and there the
lack of easy whitespace control hurt there.
Would it be feasible to add some logic, something along the lines of:
"Template lines containing just tags with no literal content do not
produce a line in the output (unless of course the tag itself
produces one)"
After all, new lines are easy to add, but currently painful to suppress...
Cheers,
Leon
--
Leon Matthews BSc
Technical Director, Messiah Ltd.
work: http://messiah.co.nz/
home: http://lost.co.nz/
That's... quite fantastic. A actual patch for the exactly the
behaviour I had in mind.
Why was it not commited for 1.3 or 1.4? From my perspective it's a
big win, and reading the bug notes, the issues -- backwards
combatibility, docs, tests -- seem to have been addressed.
It looks like a lot of work looks went into this patch, why did it stall?
Leon
Same reason any ticket stalls - it seems that nobody felt strongly
enough about it to put the time into reviewing and thoroughly testing
the patch and marking it Ready for Checkin. If you'd like to see it in
(post 1.4 at this point, of course), feel free to do that!
Carl
Fair enough. I realised after posting that my question was
particularly poorly timed, given where we are in the release cycle. I
apologise for that -- I was overcome with excitement to find that
somebody had already written the patch I wanted!