Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#2741 closed enhancement (wontfix)

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

Reported by: napalm@… Owned by: adrian
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: UI/UX:

Description

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 node.id|in:open_nodes %}
  <!-- expand this node -->
{% endif %}

Filter definition:

@register.filter(name='in')
def inside(value, arg):
    return value in arg

Change History (6)

comment:1 Changed 9 years ago by anonymous

  • Cc napalm@… added

comment:2 Changed 9 years ago by adrian

  • Resolution set to wontfix
  • Status changed from new to closed

Marking as a wontfix for now.

comment:3 Changed 9 years ago by napalm@…

What does that mean? Is it a maybe?

comment:4 Changed 9 years ago by adrian

It means "no." :)

comment:5 Changed 9 years ago by napalm@…

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?

Regards,
João

comment:6 Changed 8 years ago by ubernostrum

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