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 https://groups.google.com/d/msgid/django-users/CAL13Cg_Fx9R012t9KKDEQ8LajJNOpbXGRUyNR9%2BYXkMBZXzzCg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
