Opened 18 years ago

Closed 18 years ago

Last modified 17 years ago

#2741 closed enhancement (wontfix)

Filter to check if a value/key exists inside a list/dict

Reported by: napalm@… Owned by: Adrian Holovaty
Component: Template system Version: 0.95
Severity: trivial Keywords: filter template in
Cc: napalm@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


The summary fully describes the purpose of this filter.
In my opinion it's so simple and useful that it deserves to be together with the bundled filters.

Usage example:

{% if|in:open_nodes %}
  <!-- expand this node -->
{% endif %}

Filter definition:

def inside(value, arg):
    return value in arg

Change History (6)

comment:1 by anonymous, 18 years ago

Cc: napalm@… added

comment:2 by Adrian Holovaty, 18 years ago

Resolution: wontfix
Status: newclosed

Marking as a wontfix for now.

comment:3 by napalm@…, 18 years ago

What does that mean? Is it a maybe?

comment:4 by Adrian Holovaty, 18 years ago

It means "no." :)

comment:5 by napalm@…, 18 years ago

I must say I'm surprised that you having used django more intensively that no one else, have never felt the need for such an obvious filter.
Not that it counts for a thing but for the record I've used it twice for my first django project and I can imagine using a lot more.

Before we close the subject can I ask you why do you feel this simple utility does not fit the django requirements?


comment:6 by James Bennett, 17 years ago

I can think of two reasons why this shouldn't go in.

First of all, it's largely redundant; the template system's dot syntax already does a dictionary-style lookup as its first attempt to resolve something, so this functionality is already built-in for any data type which implements __getitem__.

Second, and more importantly, this is an indicator that application logic is leaking into the presentation layer. Let's assume you have a template which displays a list of messages, and it's possible that one of them describes a critical error. What you might want is to be able to do

{% if "Critical system error"|in:message_list %}

and then change the presentation of the page.

But that's where the leak comes in: the fact that, in this case, a critical error occurred is part of the application state, not the presentation state, and the application should communicate its state more clearly so the presentation layer doesn't have to hunt to find out about it (say, by passing a boolean criticial_error_occurred to the template, set True or False as appropriate).

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