On 16/11/11 09:12, Roald wrote:
> Hi all,
>
> Can anybody explain why template tag libraries are loaded from
> *inside* a template? The more I work with them, the more I get the
> feeling that specifying which template tags are available in a
> template should be specified in the view-code (or more general: the
> thing that loads/renders the template). Why would I, as a back-end
> developer, make *all* of my template tags available to the front-end
> developer in *all* templates?
>
> A great benefit of moving the template tag library loading to code,
> would be that the template language could also be safely used in
> CharFields/TextFields, without the risk of users using unwanted
> template tags.
>
> Of course, for backward compatibility, this can't be changed. The
> thing I'm most interested in, though, is restricting the template tag
> libraries that can be used in a template from my view-code. This can
> be done in a backward compatible way.
>
> Opinions?
>From my perspective, putting the template tag libraries in the view is
absolutely the wrong thing to do, for a number of reasons:
1) If I'm reading a template and come across a template tag I don't
understand, I have to go and find the view it is called from to work out
what template tag library it might be from. The information is much
better off in the template.
2) A single template might be used by multiple views. If views are
responsible for setting the libraries available, they now have duplicate
content.
3) If it was done this way, then the available libraries would have to
be inherited by included templates, and templates that are 'extended
from'. This makes things even worse for chasing down which template tag
libraries are in use, especially as a single template can be included
from multiple places. If you add in the fact that a tag from custom
template tag library can shadow a builtin, and the deliberate mechanism
we have for choosing a new version ({% load url from future %}), things
are getting pretty diabolical.
Template tags essentially form part of the syntax of the template, and
putting that information outside the template really doesn't make sense.
As for the need to limit which libraries are allowed for a template, my
solution would be to do this:
{% load foo bar baz %} {# No others allowed for this template #}
Front-end developers are on the same team. If they refuse to follow
instructions like that, you should sack them.
You shouldn't be using the template system in situations where you have
people who are not trusted, because it simply does not have the security
necessary for it to be made available to potentially malicious users. It
was never designed with that in mind, and would probably have dozens of
major security flaws if you use it in that way. (The protection that
exists against use of unsafe methods being called is protection against
*accidental* use of those methods, not against malicious users).
So, if this feature request (restricting the available template tag
libraries) is part of a security feature, I'm -1 on it, because it
implies an existing level of security in the template system that
doesn't exist. To put it another way, if your use case is "allow end
users to use the template system safely", this feature wouldn't come
close to doing that. If your use case is "stop front-end developers
deliberately doing naughty things", I'd say the solution can't be a
technical one.
Regards,
Luke
--
You meet a lot of smart guys with stupid wives, but you almost
never meet a smart woman with a stupid husband. (Erica Jong)
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
