Since we're on the topic.... after some goading from loic I did figure out a backward-compatible way to add call arguments to the filter expression syntax.
Essentially, you distinguish between foo|filter:arg and foo|filter(arg...) by looking for : or ( The same parsing could let you have dict lookups, etc. I was going to implement something like this in django-contemplation [my template-engine-as-gedanken project] by mangling the AST.. thus letting me keep performance as well as having Python syntax. I'm happy to have a go at implementing simple dict syntax, if there's a chance it will be accepted. -- Curtis On 4 November 2013 11:24, Russell Keith-Magee <[email protected]>wrote: > > On Sun, Nov 3, 2013 at 9:57 PM, Emanuele Bertoldi < > [email protected]> wrote: > >> I've opened a ticket (#21370) with a proposal for the *inclusion of a >> generic "getter" filter* in the built-in library. >> >> *Why?* >> >> Well, because at the moment Django's template system really lacks of >> support for retrieving data from existing context variables in all the >> cases in which the name of the attribute we need is determined at execution >> time. >> > > It's worth pointing out that this is something the Django core team has > historically rejected, on the basis that it's a slippery slope from here to > turning Django's template language into a fully featured programming > language. So -- fair warning -- the default answer here is going to be > "No"; it's going to take some convincing to flip that position. > > However, I will admit that this is a use case for which I have some > sympathy. Cross-cutting arrays of data is one of those things that is a lot > more complex to do in the context than it would be to do using a simple > lookup in a template. > > Formally, I'm probably +0.1 :-) > > >> *Syntax:* >> >> {{ object|get:attr_name }} >> >> Of course the idea is to add a multi-purpose filter which covers >> different use cases (model instances, arbitrary objects, dicts, lists, >> tuples, etc.) >> > > *IF* we are to add this, I'd be inclined to do this as a primitive of the > template language itself, rather than as a template filter. This is a > fundamental concept in context lookup, not a data transformation (which is > what filters generally represent). > > The minimal syntactic solution would be to use the colon operator to > denote arguments in the same way as it does for filters: > > {{ object:attr_name }} > > or, by introducing square brackets as parseable symbols in the template > language: > > {{ object[attr_name] }} > > The latter has the benefit of being compatible with Jinja syntax; the > downside is that Django templates starts to look even more like a > programming language. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAJxq84_QtcWsop_hPYorOdYUnWxJVVe39E%2Bxu%3DAyUtd3GpP1HQ%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAG_XiSCLh_iuYniyz5CJKU1KabQnkhd_nDUx5DveYinBMJSjcA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
