Change History (24)

What does {{ dict|key:key_name }} add that {{ dict.key_name }} doesn't already do (the dot syntax already does a dictionary key lookup as the first attempt to resolve to a value)?

Also, the proposed implementation doesn't meet the standards for built-in filters: it doesn't catch KeyError and so could propagate an exception all the way back to the template (filters should fail silently -- in this case the appropriate behavior is to catch KeyError and return an empty string or the value of TEMPLATE_STRING_IF_INVALID).

With {{ dict|key:key_name }} key_name holds actual key dict should be looked up while {{ dict.key_name }} look ups only 'key_name' key in dict. So with the former if key_name variable contains value 'test_key' {{ dict|key:key_name }} will result in

dict['test_key']

Here is improved version of filter(silly me), i will make patch against trunk, add documentation and tests in case it will be approved by core devs.

Filter to get dict's value by key name →
Filter to get dict's value by key name (for the purpose of enabling variable lookups in the template)

Triage Stage:

Design decision needed →
Unreviewed

Type:

→ New feature

UI/UX:

unset

Dear "Django's lead developers":

Being unable to perform variable lookups in the template is the bane of Django.
Please be aware that after reviewing #12486, #1495, #959, and #577; I have determined that #3371 most appropriately addresses this source of Django's impotence. The individuals responsible for closing this ticket (@jacob, @ubernostrum) have provided nothing but non sequitur as motivation for its closing. I find it necessary to reopen #3371, and I will continue to reopen it until Django is capable of performing variable lookups in the template, or until a SOUND reason is given for insisting that Django inflict such an undue handicap on perfectionists with deadlines.

Sadly, it appears that this trivial exercise in templating is "out of scope" (@jacob) or even "impolite" (@ubernostrum). While not providing any alternatives to (or even any sound reasons for rejecting) @nullie's fix, one might speculate that the cited "Django's lead developers" would rather we perform such templating in the views.py:

In further defence of @nullie's fix: note that when the data does not exist, the filter simply returns None. This is advantageous because we can test for None in the template using an if-else block. When None is encountered, we make the TEMPLATE level decision of what content shall be displayed. We may then display that content (even change our minds later) without ever concerning ourselves with python code.

It is my position that the example of students and courses provided above is hardly a manifestation of an "out of scope" use-case for Django projects. @nullie has proposed a solution and it was rejected without any sound criticism. A blind eye is being turned on perfectionists with deadlines. Altogether, I trust that I have demonstrated a sufficient condition for reopening #3371 (regardless of how impolite @ubernostrum feels such a sufficient condition is). Please expect #3371 to continue being reopened until a sufficient condition is provided for closing it.

We have a simple and clear procedure if you disagree with a wontfix decision: rather than have a fight about it in the ticket, start a discussion on the django-developers mailing list, where it will likely also reach a broader audience. Which is exactly what I suggested when I last closed this ticket.

Please expect to have your arguments excluded from consideration until you respect what is a simple and useful procedure for raising disagreement about a decision on a ticket. Please also expect that if your approach is to petulantly re-open a ticket over and over again out of anger, steps will be taken to remove your ability to behave in such a fashion.

We have a simple and clear procedure if you disagree with a wontfix decision: rather than have a fight about it in the ticket, start a discussion on the django-developers mailing list, where it will likely also reach a broader audience. Which is exactly what I suggested when I last closed this ticket.

Please expect to have your arguments excluded from consideration until you respect what is a simple and useful procedure for raising disagreement about a decision on a ticket. Please also expect that if your approach is to petulantly re-open a ticket over and over again out of anger, steps will be taken to remove your ability to behave in such a fashion.

Once again @ubernostrom, you are only providing scape-goating and argumentation ad hominem in your effort to throw bona fide use cases under the bus.

It can be said with complete confidence that jinja2 is outside of the scope of #3371. @nullie has already suggested fix superior to configuring jinja2. Unless you are suggesting that jinja2 should replace the Django templating language as the way to resolve #3371, your pasting of urls to ambiguous lists of hyperlinks contributes absolutely nothing to this discussion.

These two comments direct zero focus to the subject of #3371 which is that of performing variable lookups in the template. Instead you attempt to obfuscate #3371 with irrelevant dogma.

If your recommendation to resolving failures of the Django templating language (as addressed by #3371) is to replace it with jinja2 as the defacto templating language, then #3371 should be reopened until that fix has been implemented. Simple, no?

I agree with the reasoning about why the discussion should be moved to mailing list. This ticket ranks high up in google search for this issue and it'll be a big help for many newbies to simply find a workaround without opening security holes etc.. My polite request to core developers is to simply comment on usability/security of this solution. Most of us are pretty happy with Django templating language and wouldn't want to switch to Jinja2. However, often there are instances where a variable lookup is needed as witnessed by the activity on Stackoverflow.

The Core Developers already commented on your solution back in comment 13:
Google.com/search?q=how+do+i+use+jinja2+with+django

Combined with https://code.djangoproject.com/ticket/2594#comment:58, it is pretty clear that the core developers are following an abandon-ware model to the development of the Django Template system. It really is too bad that they don't just come out of the closet and deprecate the darn thing.

There are some practical issues with deprecating 10% of your framework before you've actually implemented a replacement :-)

and

Google.com/search?q=how+do+i+use+jinja2+with+django

Does that mean Django core developers are endorsing Jinja2 over their own template system? Should I be migrating my system to something like ​django-jinja?
My impression from the conversation of this ticket is that Django developers have no interest in fixing simple but glaring issues with their system, and instead recommend usage of another, competing tool.