#2741 closed enhancement (wontfix)
Filter to check if a value/key exists inside a list/dict
Reported by: | 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 |
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 by , 18 years ago
Cc: | added |
---|
comment:2 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:5 by , 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?
Regards,
João
comment:6 by , 18 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).
Marking as a wontfix for now.