1.2 Proposal: Extra template tags and filters
Richard Davies
With 1.1 out of the door (great!), here's a thought for 1.2...
I often end up writing the same couple of template tags and filters. I
think some of these are general enough and useful enough that they
should be considered for basic Django 1.2, even though they're fairly
easy to write as add-ons. Here is my wishlist - please feel free to
comment on any others that you would like to see and on any of mine
where I've missed an obvious way to use the existing tags.
Filter: get
The built in dot (.) operator is great for accessing dictionary
lookup, attribute lookup, etc. However, it doesn't work when the
attribute/dictionary element is also a variable. I use a 'get' filter
with code like:
{% for k in keys %}
Value for {{ k }} is {{ d|get:k }}<br/>
{% endfor %}
where I'd like to just write d.k
I couldn't find another way, and often end up writing this operator,
so think that it or an equivalent mechanism should be built in.
Tag: ifstartswith
I find this very useful in writing menus, navigation bars, etc. since
I'm often checking whether the URL is within a given subdirectory.
Filters: sort and sortreversed
We have dictsort and dictsortreversed already, but what about sorting
simple lists? e.g.
{% for i in i_list|sortreversed %}
Yes, I could usually sort the list before passing it into the
template, but it's nice to be able to do it in the template at well!
Cheers,
Richard.
Andrey Fedorov
Filter: get
+1, I've also written this filter (lambda d, v: d.get(v, None)). Would be nice to have it standard.
No opinions on the others.
- Andrey
Jacob Kaplan-Moss
Davies<richard...@elastichosts.com> wrote:
> With 1.1 out of the door (great!), here's a thought for 1.2...
Actually, it's about six thoughts. I'll give you my quick thoughts
below, but if you're serious about discussing this stuff you'll want
to have a thread for each of 'em so that you can easily refer back to
the discussion later.
> Filter: get
This has been discussed ad nauseam in the past, and has been rejected
repeatedly. If you want to bring it up again, you'll need to review
the previous discussion and bring to the table something new.
> I couldn't find another way,
Here's two:
1. ``{% for key, value in dict.items %}``
2. Make your view provide data that's easier for a template to consume.
> Tag: ifstartswith
> I find this very useful in writing menus, navigation bars, etc. since
> I'm often checking whether the URL is within a given subdirectory.
This leads naturally to pretty scare feature creep. If we have
startswith, why not ifendswith? ifcontains? ifdoesntcontain?
ifcontainssomewhereinthemiddleafterthethirdcharacter?
There's a reason we support custom template tag libraries: they mean
this stuff doesn't have to go in core, and so the general feature
creep isn't a problem.
> Yes, I could usually sort the list before passing it into the
> template, but it's nice to be able to do it in the template at well!
Not only *could* you sort the list in the view, you *should* sort the
list in the view. That's what views are *for*.
Also, try ``{% for x in list reversed %}``.
----
Okay, I didn't mean to rain on your parade there, but I'm strongly
opposed to feature creep in the template language. If you can't
articulate why something *MUST* be a builtin -- why it Just Won't Do
to have it in an external library -- it's going to be very hard to
convince me to add it.
Jacob
Andrew Gwozdziewycz
Davies<richard...@elastichosts.com> wrote:
>
> Hi all,
>
> With 1.1 out of the door (great!), here's a thought for 1.2...
>
> I often end up writing the same couple of template tags and filters. I
> think some of these are general enough and useful enough that they
> should be considered for basic Django 1.2, even though they're fairly
> easy to write as add-ons. Here is my wishlist - please feel free to
> comment on any others that you would like to see and on any of mine
> where I've missed an obvious way to use the existing tags.
>
>
> Filter: get
> The built in dot (.) operator is great for accessing dictionary
> lookup, attribute lookup, etc. However, it doesn't work when the
> attribute/dictionary element is also a variable. I use a 'get' filter
> with code like:
>
> {% for k in keys %}
> Value for {{ k }} is {{ d|get:k }}<br/>
> {% endfor %}
>
> where I'd like to just write d.k
What about allowing {{ d.'k' }} ? It's less typing, and maps more to
a dict lookup.
And, you could still do {{ d.'k'|default:'Hello' }} for a default value,
> Tag: ifstartswith
> I find this very useful in writing menus, navigation bars, etc. since
> I'm often checking whether the URL is within a given subdirectory.
I'm a fan of having more if tags, but am not a fan of having if tags that
require me to remember all of the suffixes. Perhaps a smarter if tag in
general would be better...
Andrey Fedorov
This has been discussed ad nauseam in the past, and has been rejected repeatedly.
- Andrey
Jacob Kaplan-Moss
> Sorry, new to the group - is there an easy way to search old threads? Google
> keeps pointing me to the docs...
It's in the footer that Google adds to every message:
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en
Jacob
dc
> startswith, why not ifendswith? ifcontains? ifdoesntcontain?
> ifcontainssomewhereinthemiddleafterthethirdcharacter?
Maybe it's time to close it in favour of "smart if tag" suggestion for
1.2?
[1] http://code.djangoproject.com/ticket/8087
Russell Keith-Magee
A smarter "if" tag has already been proposed as a v1.2 feature, and I
think there is some support for it. However, "smarter" doesn't mean
"exposing everything that Python can do" - it just means clarifying
the syntax for some of the simple cases. ==, < >, and "in" are
possible candidates. "startswith" sounds a bit too much like "logic in
the template" feature creep to me.
Yours,
Russ Magee %-)
John
wrote:
http://code.djangoproject.com/ticket/5025 seems to have the right idea.