text: Opened 7 years ago
  Closed 7 years ago
  Last modified 7 years ago
  #2741 closed enhancement (wontfix)
  Filter to check if a value/key exists inside a list/dict
  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
  Attachments (0)
  Change History (6)
  comment:1 Changed 7 years ago by anonymous
  - Cc napalm@… added
  comment:2 Changed 7 years ago by adrian
  - Resolution set to wontfix
  - Status changed from new to closed
  comment:3 Changed 7 years ago by napalm@…
  What does that mean? Is it a maybe?
  comment:4 Changed 7 years ago by adrian
  It means "no." :)
  comment:5 Changed 7 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 7 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).
  Marking as a wontfix for now.