1.2 Proposal: Extra template tags and filters

7 views
Skip to first unread message

Richard Davies

unread,
Aug 11, 2009, 10:50:55 AM8/11/09
to Django developers
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

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

unread,
Aug 11, 2009, 11:09:47 AM8/11/09
to django-d...@googlegroups.com
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

unread,
Aug 11, 2009, 11:19:33 AM8/11/09
to django-d...@googlegroups.com
On Tue, Aug 11, 2009 at 9:50 AM, Richard
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

unread,
Aug 11, 2009, 11:20:14 AM8/11/09
to django-d...@googlegroups.com
On Tue, Aug 11, 2009 at 10:50 AM, Richard
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...

--
http://www.apgwoz.com

Andrey Fedorov

unread,
Aug 11, 2009, 11:32:31 AM8/11/09
to django-d...@googlegroups.com
This has been discussed ad nauseam in the past, and has been rejected repeatedly.

Sorry, new to the group - is there an easy way to search old threads? Google keeps pointing me to the docs...

- Andrey

Jacob Kaplan-Moss

unread,
Aug 11, 2009, 11:57:03 AM8/11/09
to django-d...@googlegroups.com
On Tue, Aug 11, 2009 at 10:32 AM, Andrey Fedorov<anfe...@gmail.com> wrote:
> 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

unread,
Aug 11, 2009, 12:03:41 PM8/11/09
to Django developers
> This leads naturally to pretty scare feature creep. If we have
> startswith, why not ifendswith? ifcontains? ifdoesntcontain?
> ifcontainssomewhereinthemiddleafterthethirdcharacter?

Jacob, there is a ticket for ifin and ifnotin tags in DDN state [1].
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

unread,
Aug 11, 2009, 6:56:41 PM8/11/09
to django-d...@googlegroups.com

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

unread,
Aug 14, 2009, 7:08:23 PM8/14/09
to Django developers
On Aug 11, 7:50 am, Richard Davies <richard.dav...@elastichosts.com>
wrote:
I would add to your list a truncatechars style truncation filter.
http://code.djangoproject.com/ticket/5025 seems to have the right idea.
Reply all
Reply to author
Forward
0 new messages