On 11/04/2013 04:24 AM, Russell Keith-Magee wrote: > > On Sun, Nov 3, 2013 at 9:57 PM, Emanuele Bertoldi > <[email protected] <mailto:[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 %-)
Hi! I know this is probably wontfix, but I'll bite the bullet and say that this has less to do with implementing a Turing-complete template language (which is obviously an issue in a need of urgent attention :-)) and much more to do with template reusability. :-) Let's say you are working on a system in which users can be assigned different roles, and, depending on a given role and on the context, the user is able to view dynamic number of model fields and attributes. The most clean and DRY way to work with templates in this situation (as I see it) is to use a solution similar to the one proposed by the parent poster. I'm not even talking about a situation (which you'll obviously consider much more esoteric) when you have truly dynamic Django models (the ones that have fields defined by the users during runtime). `get_FIELD_display` anyone? I'm not going to say that this is a very big deal, of course, since a custom template filter is easy to write. Philosophically speaking, by insisting that this issue should be solved outside of templates and inside of views, you are putting something that doesn't belong there, since the parent ticket is about representation and not about application logic. Whether his proposal is sufficiently general-purpose to be included in Django, is another question. I think it is general-purpose. Best regards, Ivan > -- > 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/5277DA5D.80409%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
