On Nov 17, 12:05 am, Luke Plant <l.plant...@cantab.net> wrote:
> 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.
I agree, hadn't given much thought to readability
> 2) A single template might be used by multiple views. If views are
> responsible for setting the libraries available, they now have duplicate
> content.
I agree that we should avoid code duplication. But I think that that
doesn't have to be the reason to load template tag libraries from the
templates. It could make sense to turn the (html-) template into a
python object in one place (maybe <app>/templates.py), and use this
python object in your views. Then the libraries could be set in this
file (<app>/templates.py).
> 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.
Agreed
> Template tags essentially form part of the syntax of the template, and
> putting that information outside the template really doesn't make sense.
I don't really see this point. Along this line of thinking you could
also say that defining template tags should be done inside of
templates. Before you know you have recreated PHP ;-).
> 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.
I'm not in the position to, so that's not really an option ;-).
> 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.
OK
--
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.
