On Mon, Mar 12, 2018 at 5:44 PM, Craig de Stigter <
craig.destig...@koordinates.com> wrote:

> Thanks for the reply.
> So I guess there are actually now two types of templates, and they have
> incompatible API. Neither is deprecated.
> Has this confused anyone else? Is this a desirable/necessary situation?

Here is what happened:

Django originally shipped with one template language, and that was the
only thing its template framework understood. The interface for it
involved instances of django.template.Template and rendered them using
instances of django.template.Context.

When Django grew support for using multiple template languages, this
became a problem since Django's original template language was the
only one that understood the Django Context object. So the
engine-based interface wants you to pass in a dict instead of a
Context for rendering, which then lets the underlying template
framework figure out what template-language-specific type of object to
convert it into. If you happen to use the original Django template
language, of course it gets converted into a Context instance, but
Django has no way of knowing in advance that this will happen.

The old django.template.Template/django.template.Context interface
hasn't been deprecated, because for users who use only the original
Django template language, it still works and is still a very
convenient and simple API, and there's no need to make them deal with
the indirection of working through the template-engine API. The only
time you need to know or care about the engine API and using plain
dicts is when you start using some other template language with
Django, so the complexity of dealing with the engine API gets deferred
to that point.

The problem you're running into, of course, is an old codebase where
apparently some developers used one of these APIs while some
developers used the other API. And the solution is to pick one and
force the developers on your team to use only that API going forward.

If you know that you are always going to use the original Django
template language, and not use any other language (like Jinja), then
using django.template.Template/django.template.Context is still fine
and is still supported. If you think there's even a small chance that
at some point in the future you might want a different template
language, use the engine API.

Also, it's generally best to avoid from_string(); while it may seem
convenient, it can cause situations where you have template code
hidden somewhere other than where you store your templates. Just make
a real template and use the loader to go find it. And importing
through django.template.base instead of just through django.template
is probably a bad idea; I don't think we have any kind of
compatibility guarantee for django.template.base to keep working,
while we do have one for django.template to keep working. This is why
it's good to use the import path given in the Django documentation,
rather than trying to track down the "real" location of a definition
and import from there instead.

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to