Russell Keith-Magee wrote:
> 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 :-)
>
Well, I understand the point but I don't honestly could think to attribute
lookup as an exclusive feature of "programming languages".
At the end we're talking about "getting" information, not "setting": if you
want to show them, you need to retrieve them from somewhere. That's my
humble opinion and, maybe, a good general principle to distinguish between
what should be included in template system and what not (then, of course,
there're always exceptions).
> *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.
>
That would be awesome.
Jonathan Slenders wrote:
> - The only operators that we should implement are those necessary for data
> lookups. We shouldn't implement addition or subtraction operators for
> example.
>
What about the *add* filter? ;)
Again, we have to remember that in programming there are always exceptions.
Be too strict to just a theoretical principle could really miss the contact
with the reality. Frankly speaking, I understand that we don't need another
programming language for templates but the "with" statement and the already
cited "add" filter are examples of exceptions at the rule to make the
template system something realistically useful (do I have to mention all
the CSS frameworks, sessions/cookies and the new features of HTML5 on
storage-side as references to the historical failing of too-strict
markup-only ideas in real world?)
Cheers,
Emanuele
--
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/c7d3dfea-7e83-4922-af21-f1b065aa4845%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
