Rusell's last proposal, using the square brackets sounds the best and
future proof to me. I think it should be something different from the
calling syntax of template tags, because calling of an object or retrieving
a property is not the same.
While I like it, I don't say we should necessarily allow it, but the square
brackets allow for nesting. e.g.
{{ object[attribute.name] }}
or even:
{{ object[attributes[something].name] }}
Semantically, the following tree are the same:
{{ object.name }}
{{ object["name"] }}
{% with "name" as var %} {{ object[var] }} {% endwith %}
Another reason for using another syntax for filters and attribute lookups
is that I think it can be possible in the future to use any arbitrary
object from the context as a filter.
Say, for instance that from a view, we put a dictionary of filters in the
context. The following would be possible.
{% my_var|my_filters["escape"]:param %}
As said, we should be careful not to create a complete programming
language. For me, that means:
- Template tags should never cause side effects. (They should not be able
to change anything in the database or anywhere else. However, that's hard
to force!)
- The only operators that we should implement are those necessary for data
lookups. We shouldn't implement addition or subtraction operators for
example.
- The template author shouldn't have to care whether the attribute lookup
happens in a dictionary (through getitem) or in an object (through getattr).
- The template author shouldn't be concerned with how expensive some
attribute lookups are, for instance when an attribute lookup causes a
database query. (That's also a hard one, we cannot make all lookups cheap,
or forbid expensive lookups.)
I think in order to avoid that many projects will create their own template
filters and template tags as workarounds to syntax limitations, we really
shouldn't artificially limit the syntax to the most obvious lookups. (I'm
rather against the idea of custom template tags, but not against filters.)
B.t.w. if anyone has template engine related patches ready, I'm always
willing to review it.
Cheers,
Jonathan
Le lundi 4 novembre 2013 01:24:45 UTC+1, Russell Keith-Magee a écrit :
>
>
> On Sun, Nov 3, 2013 at 9:57 PM, Emanuele Bertoldi
> <emanuele...@gmail.com<javascript:>
> > 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/7a3368e7-1e89-4433-b390-b0ad7a30ef3c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
