Let jinja throw errors on undefined variables

[Elrond]

(this is to discuss this and then possibly implement it.
Implementing is **very** easy).

Currently jinja2 replaces ``{{ not_known }}`` by the empty string.
The question is, wether it would be better for it to throw an
error? Rationale being: Either it's a typo, or it's an error for
the variable to be referenced but not being there.

Does that make sense?

Enabling this:

::

    mediagoblin/tools/template.py:
    @@ -43,6 +43,7 @@ def get_jinja_env(template_loader, locale):
    
         template_env = jinja2.Environment(
             loader=template_loader, autoescape=True,
    +        undefined=jinja2.StrictUndefined,
             extensions=['jinja2.ext.i18n', 'jinja2.ext.autoescape'])

[Christopher Allan Webber]

Hm. There might be some places where this would be nicer.

I remember when working with ZPT that it would complain on these
things, it was nice in some places {{ foo }} but less in other
places {{ objyoudohave.fooyoudont }}... being able to call
attributes that you don't actually have and it going silent is
nice. That said I remember a few years ago saying that ZPT
complaining about such things was a significant feature in
comparison to Django's templates.

How's that for a non-answer ;)

[Elrond]

jinja2 has a ``defined`` test. That should help if you have an
attribute that purposefully might or might not exist.

Edit: We might also conider
`jinja2.DebugUndefined <http://jinja.pocoo.org/docs/api/#jinja2.DebugUndefined>`_

[Elrond]

Okay, I have enabled this. And fixed two breaking places (simple).

I leave this bug open for the next 14 days, if this all turns out
to be a bad idea.
Let's see!

Commit: f1cdd278e7cf195e485567ed0d0d8a90cad81e48 and following

[Elrond]

13 days over, okay.
We had a small bit of pain here and there, but it generally was
acceptable.

[Will Kahn-Greene]

The original url for this bug was ​http://bugs.foocorp.net/issues/691 .