views:

1612

answers:

5

After reading the Jinja2 documentation, I'm interested in employing it in future Django projects. However, I'm wondering if anyone has encountered any drawbacks or gotchas when using Jinja2 templates with Django? If so, how did you work around them?

I wouldn't mind hearing about positive experiences either, just to get a good cross section of the best and worst of Jinja2.

+2  A: 

I haven't used Jinja2 with an actual Django site yet, but I did convert an application using Django templates in standalone mode over to Jinja2 templates. The only (very minor) problem I encountered was lack of the {% spaceless %} template tag.

Van Gale
One thing I haven't explored yet is Jinja's extensions; how do they compare to user defined template tags in Django?
Soviut
Just in case you haven't seen Armin's article http://lucumr.pocoo.org/2008/9/16/why-jinja-is-not-django-and-why-django-should-have-a-look-at-it you should read it. At the top he has a link to a project to convert django->jinja2. It can't do custom tags, so I imagine they all need to be rewritten.
Van Gale
You should make your comment an answer, its worth a vote up.
Soviut
For future visitors of this question: http://github.com/cdleary/coffin/tree/master is a nice app billing itself as a Jinja adapter for Django.
Van Gale
+1  A: 

Extending Jinja2 is much harder than Django template system (I'm talking about templatetags). While most of inclusion tags functionality can be achieved using macros in Jinja (they even seem to be more appropriate), writing bit more complicated tags is really hard in Jinja (see the docs for yourself).

Other than that, the only obstacle are Django-based habits... ;)

zgoda
+6  A: 

I use Jinja2 in some of my projects and love the extra expressiveness it gives me. I can keep my presentation logic and application logic separate, but I don't have to bend over backwards to call into a function/method I've designed specifically for my presentation layer.

In addition to what's already been listed by other posters, here are some things that I've found:

  • The Admin app is tightly coupled to Django templates
  • The default views and decorators that come with the Auth app (and elsewhere) are coupled to Django templates, so you may have to duplicate the effort if you want to use your Jinja2 templates for login/logout/etc

Behaviorally, Django templates will escape its output by default whereas Jinja2 will not. I think either approach has its own merits, but you have to keep this in mind if you are switching between the two.

Joe Holloway
But, to be clear, HTML escaping by default in Jinja 2 is just a configuration option away.
Dan Ellis
+1  A: 

There's been some new code added in the Django trunk that lets you write TemplateLoaders and Template classes that can be used to work with different template languages. Docs have been added for it at http://docs.djangoproject.com/en/dev/ref/templates/api/#using-an-alternative-template-language, and it will be in the 1.2 release. This should cut out most of the gotchas with things like using custom templates for login, logout, admin etc.

An alternate solution is to use a layer on top of Django, like Chouwa or Djinja2. You will have issues getting Django's builtin views to use your templates, but it works if you don't want to use Django trunk.

Once you've done either of those, the only really major issue is that most of the stuff Django exposes to templates (especially for the comments framework) is exposed in custom tags, which don't translate to Jinja2. Sadly, backwards-compatibility concerns don't see this changing anytime soon.

LeafStorm